Customer consent for support access and internal approval are separate controls. Internal approval answers “should this staff member open this account now?” Customer consent answers “has the customer agreed to it?” One approval can’t stand in for the other, and a support process that records only one of them leaves a gap.
Most SaaS teams already have some internal approval, even if it’s a manager saying yes in Slack. Fewer have decided what the customer has agreed to and how they’d prove it. This guide covers the options, from notice in your terms to customer-approved requests, what to record, and how to tell customers. It isn’t legal advice: what you must do depends on your contracts and the laws that apply to you, so take the policy to your counsel.
What is the difference between customer consent and internal approval?
Internal approval is your organization deciding that a specific staff member may access a specific customer account, with a scope and a time limit. Your team grants it, and it protects the customer from your own staff.
Customer consent is the customer agreeing to that access. It can be general, such as accepting terms that describe support access, or specific, such as approving one request for one case.
Customer notice sits between the two. You tell the customer that access can happen or did happen, without asking first.
| Internal approval | Customer consent | Customer notice | |
|---|---|---|---|
| Who decides | Your approver | The customer | Nobody; it informs |
| When | Before each session | Before access, at some level | Before or after |
| Protects against | Unnecessary or unauthorized staff access | Access the customer didn’t expect | Surprise and loss of trust |
| Typical evidence | Approval record | Terms version, message or grant | Notice text and delivery |
Many enterprise vendors use both. When a customer turns on Microsoft’s Customer Lockbox (opens in a new tab), a Microsoft support manager approves each request first, and then the customer’s designated approver must approve it too.
What are the options for customer consent to support access?
There are five common models, from lightest to strictest.
1. Notice in your terms. Your terms or privacy notice say support may access accounts to resolve issues. Consent is general and given at signup. It’s simple and works for routine, read-only troubleshooting, but customers rarely remember it.
2. Per-ticket permission. The agent asks in the ticket (“May we look at your account to investigate?”) and the customer replies. The ticket thread is the record. It’s easy to adopt, but the person replying may not have authority over the whole account.
3. Customer-initiated grant. The customer turns on access for a set period from their own settings. In Salesforce, users can grant login access (opens in a new tab) to their company’s administrators or to Salesforce support, choosing the duration, up to a maximum of one year. The same page notes that company administrators can access a user’s account by default without any action from the user. Customer grants and internal access can coexist.
4. Customer-approved requests. Your support team requests access, and an admin at the customer approves it. Okta’s read-only impersonation for support cases (opens in a new tab) requires customer approval from a Super Admin or the admin who opened the case. Access is tied to that case, expires automatically and can be revoked by clearing a checkbox. Okta doesn’t send an automatic notification, so the engineer has to ask for approval directly. In Customer Lockbox, a request that isn’t approved within 12 hours expires (opens in a new tab) and grants no access.
5. Opt-out and transparency. Some customers don’t want their accounts accessed at all. PropelAuth, for example, offers an organization blocklist (opens in a new tab) so that no user in a listed organization can be impersonated. At the other end, Google’s Access Transparency (opens in a new tab) gives customers logs of Google personnel access, including the reason and the time. That’s notice after the fact, not consent.
Which model fits which situation?
Match the model to the risk, not to the loudest customer.
| Situation | Reasonable model | Why |
|---|---|---|
| Self-serve plan, read-only troubleshooting | Notice in terms, plus internal approval | Low risk, high volume |
| Investigating a ticket the customer opened | Per-ticket permission | The customer is already in the conversation |
| Write access or a fix in the account | Per-ticket permission at minimum | The customer should know changes will happen |
| Regulated or sensitive data | Customer-approved request | The customer’s admin keeps control |
| Enterprise contract with access clauses | Whatever the contract says | The contract usually overrides your default |
| Customer that has opted out | Blocklist, no access | Make the promise enforceable |
Whichever model you pick, keep internal approval on top. Customer consent doesn’t make a staff member suitable for the job, and it doesn’t remove your duty to limit scope. A read-only session your backend enforces is still the default.
Watch for one mismatch. Consent covers what the customer agreed to, but the session is whatever your approver granted. If the customer said “look, don’t change anything” and the approved scope is write, the consent doesn’t cover the session.
What should you record?
Record enough to answer, months later, why the access happened and who allowed it. For each session:
- The basis. Terms version, ticket message ID, grant ID or customer approval ID.
- Who consented. Their user ID and their role in the customer’s organization. An ordinary member may not be able to consent for the whole account.
- What they agreed to. Read-only or changes, which user or area, and for how long.
- The internal approval. Requester, approver, reason, scope and duration.
- The session. Start, end, how it ended, and the link to the approval.
- Changes. Withdrawn consent, revoked grants and early terminations.
Reference the ticket or grant instead of copying customer content into the record. Pair this with impersonation audit logs that name the staff member, so business actions can be traced back to both the approval and the consent.
How do you tell customers about support access?
Say it plainly, in the places customers look.
- Terms and privacy notice. When support may access an account, for what purposes, and the limits you apply, such as read-only by default.
- Help center. How to ask for access, how to opt out if you allow it, and how to request a record of access.
- In the ticket. Ask before you look when your model requires it. Afterwards, summarize what you did, especially any change.
- On request. Be ready to tell a customer who accessed their account and when.
Make promises you can enforce. “We never access accounts without permission” is a policy your tools must back up, not just a sentence in your terms. The multi-tenant impersonation checklist covers the controls behind it.
How does Devora fit?
Devora’s approvals are internal. A Devora approval is your organization’s staff-access decision, not evidence that the customer consented, and the agent’s session banner isn’t a notification to the customer. Devora sends nothing to the customer and doesn’t use or end the customer’s own login. Its recording privacy docs (opens in a new tab) are explicit that customers remain responsible for their own end-user notice, lawful basis and authorization decisions.
Customer approval is on Devora’s roadmap: after an approver or admin in your organization approves a request, it will be sent to the customer, and the session can start only once the customer approves. Until that ships, you can connect consent to Devora yourself:
- Reference consent in the reason. Each Devora request carries a scope, duration and reason (opens in a new tab). There’s no ticket or consent field, so put the ticket or grant reference in the reason.
- Enforce it in your backend. Your backend impersonation handler (opens in a new tab) issues the credential, and if it throws, the session doesn’t start. Check for an active customer grant or approval there, and refuse when there isn’t one.
- Answer access questions. An admin can export the metadata Devora holds about a customer, such as requests, sessions, approvals and timestamps.
How do you test a consent check?
If you enforce consent in code, test it like any other access rule. Use synthetic customers in staging. These are pass conditions to check, not results we’ve run.
| Case | Expected |
|---|---|
| No grant or customer approval | Credential refused, session doesn’t start |
| Active grant for this user | Credential issued after internal approval |
| Grant expired before the session starts | Refused |
| Grant for a different user or organization | Refused |
| Grant covers read-only, session approved as write | Refused, or downgraded by your policy |
| Organization on the opt-out list | Refused, even with internal approval |
| Grant withdrawn mid-session | Your process ends the session and revokes the credential |
Decide your model, write it into your terms and help center, then build the check. To see how internal approval and your consent check fit together, create a Devora account and try one staging session against a synthetic customer.
Sources
- Microsoft Learn: Microsoft Purview Customer Lockbox (opens in a new tab)
- Salesforce Help: Grant login access (opens in a new tab)
- Okta Support: Approving a read-only impersonation access request for an Okta support case (updated August 6, 2026) (opens in a new tab)
- PropelAuth: Secure user impersonation (July 22, 2026) (opens in a new tab)
- Google Cloud: Overview of Access Transparency (opens in a new tab)
- Devora: FAQ
- Devora: Recording privacy and activity logs (opens in a new tab)
- Devora: Overview for teams (opens in a new tab)
- Devora: Backend integration (opens in a new tab)