The user connected an account, but setup still needs an admin: designing the permission handoff

A user clicks “Connect,” chooses an account and returns to your product. Setup still cannot continue. The missing step might belong to an administrator, or the user might have granted only some of the requested permissions. Google’s OAuth policy requires applications to handle partial consent by disabling the functionality that depends on missing access. A single green “Connected” label can therefore conceal an important difference between identifying an account and making a feature usable.

The interface needs to say which capability is ready, what remains blocked and who can act next. Google consent and Slack app approval illustrate two different permission boundaries that onboarding should preserve.

User consent and administrator approval are separate decisions

Google’s OAuth overview describes examining the scopes actually granted and matching them to the features that need access. It recommends requesting access when the relevant functionality is needed, such as calendar access at the moment a user chooses to add an event.

Slack adds an organizational review path. When app approval is enabled, members can request an app, while workspace owners or designated app managers can approve or restrict it. Optional scopes can be approved selectively. The request includes the app, requester and requested permissions, and Slack updates the original request message when its status changes.

These are distinct platform rules, not two steps every integration shares. The design implication is common: the person trying to get started may not control every prerequisite. Asking that person to keep clicking the same button will not transfer the missing authority to them.

Name the feature that is waiting

“Setup incomplete” describes your checklist. “Ask an app manager to approve posting to this workspace” describes the obstacle and its owner.

Use the smallest meaningful unit of readiness. If reading a calendar works but creating events does not, those should be separate capabilities in the product’s status model. If an organization has not approved an app, do not imply that a fresh login will fix it. A user should be able to distinguish a choice they made from a decision still pending elsewhere.

For an illustrative reporting app that can post summaries to Slack, the following is a proposed interface model. The copy assumes the corresponding state has actually been confirmed by the integration.

The “request submitted” state should come from a confirmed submission. If your product only opened the platform’s request page, say that instead. Likewise, a permission approval is not a successful post. Let each message describe the step that has actually happened.

Preserve the user’s work while somebody else decides

An administrator’s decision may arrive after the user leaves. Preserve the report, workspace choice and intended next action so that returning does not require repeating unrelated setup. Show the waiting state where the person expects to continue working, rather than burying it in an integrations settings page.

Give the user a useful alternative when one exists. In the illustrative reporting app, they may be able to inspect the report in the product while posting remains unavailable. Label that path accurately. If an export is supported, explain the export; do not imply that it establishes an ongoing integration.

The existing invited-teammate guide makes the same underlying distinction between shared setup and an individual’s next task. For integrations, preserve both the work context and the authority boundary. The person returning to a report should not have to determine which part an administrator finished on their behalf.

Ask again when the feature needs access

Google’s policy says that after a user declines a scope, a new authorization request should follow a clear indication that they intend to use the dependent feature. A consent decision should therefore produce a usable product state, not an automatic loop back to the consent screen.

For the reporting example, leave viewing available if it does not depend on the declined permission. When the person later chooses “Post to Slack,” explain the additional access and offer the relevant next step. This is a proposed interaction pattern; its implementation must follow the platform’s actual authorization flow.

Slack also documents a return to review when an installed app requests changed scopes. Previously completed setup does not mean every future permission change is approved. An established user may encounter the same handoff again, so the message should explain what changed rather than pretending they are starting from scratch.

Finish with the intended task

Test the whole handoff with representative roles: the person requesting access and the person authorized to review it. Include an approval, a restriction and a partial-permission outcome where the platform supports it. Ask each participant what is waiting and who needs to act. Confusion here is a product finding even if every permission check works correctly.

Track the transitions separately: request started, request confirmed, decision received and first successful feature use. Those events answer different questions. If approvals arrive but users never finish the first task, the next repair may be the return path. If requests are never confirmed, the earlier handoff deserves attention.

A completed connection becomes useful when the user can resume the work that motivated it. Bring them back to that work with its choices intact.

Sources

• Google: OAuth 2.0 policies.
• Google: Using OAuth 2.0 to access Google APIs.
• Slack: Manage app requests for your workspace.