<head>
<script type=“application/ld+json”>
{{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "What is an app user connector in RShift Sites?", "acceptedAnswer": {"@type": "Answer", "text": "An app user connector lets each end user of your published RShift Sites app connect their own third-party account (for example their own Gmail, Slack, or Salesforce). Your app then acts on behalf of that individual user with their own permissions. This is different from a standard app connector, where you connect a single account once and every visitor shares it."}}, {"@type": "Question", "name": "How is an app user connector different from a standard app connector?", "acceptedAnswer": {"@type": "Answer", "text": "A standard app connector uses one credential that you configure once and every user of the app shares. An app user connector keeps each end user's sign-in separate, so each person authorizes with their own account and your app reads or writes only their data, scoped to what they granted."}}, {"@type": "Question", "name": "Are user credentials exposed to the app or the builder?", "acceptedAnswer": {"@type": "Answer", "text": "No. Each user's tokens are stored encrypted in RShift Sites' connector gateway and are never exposed in the project or to the builder. Your app calls the connector through the gateway, which refreshes tokens automatically and injects the right user's credentials behind the scenes."}}]}}
</script>
</head>
App user connectors let each end user of your published app connect their own third-party account. Your app then acts on their behalf, with their own permissions and only their data. Authentication runs through RShift Sites’ connector gateway, so user tokens are stored securely and never exposed in your project.
Use an app user connector when the app is multi-tenant by nature: a signed-in user should see their inbox, their calendar, or their CRM records, not a single shared account.
Standard connector vs. App user connector
Both are app connectors and both route through the gateway. The difference is whose account the app uses.
| Standard app connector | App user connector | |
|---|---|---|
| Whose account | One account you connect once | Each end user’s own account |
| Who authorizes | The builder (or a workspace admin) | Every user, the first time they use it |
| Data the app sees | The single connected account’s data, shared by all visitors | Only the signed-in user’s data, per their granted scopes |
| Typical use | Send from a company inbox, post to one Slack workspace, query one warehouse | “Connect your Gmail”, “Connect your Salesforce”, per-user dashboards |
| Credentials | Stored once, reused for every request | Stored per user, isolated from other users |
How it works
An app user connector has two parts: a client you configure once as the builder, and the individual sign-ins your end users complete when they use the app.
1. You configure the client once
As the builder, you set up a client for the connector once for your workspace. Depending on the provider, this means registering an OAuth application with that provider (for example a Salesforce External Client App, a Databricks OAuth app, or a Snowflake OAuth security integration) and adding its details to the client. This configuration is stored securely and reused for every user who connects, and it never contains any individual user’s data.
2. Each user connects their own account
The first time one of your users needs the integration, your published app sends them through the provider’s standard OAuth consent screen. The user signs in with their own account and approves the requested permissions (scopes). RShift Sites exchanges the authorization for tokens and stores them encrypted in the connector gateway, linked to that individual user.
3. Your app calls the provider through the gateway
When your app makes a request, it goes to the connector gateway rather than directly to the provider. The gateway:
- Resolves the right user’s account for the request and confirms it belongs to that user, in this workspace and project.
- Refreshes expiring tokens automatically in the background, so users don’t have to re-authorize on every session. If a refresh token is no longer valid, the gateway returns a clear “reconnect” signal so your app can prompt the user to authorize again.
- Injects the credentials and forwards the request to the provider. The third-party tokens never touch your app code.
- Keeps users isolated: one user’s access can never be used to act as another user.
Available app user connectors
The following providers are available as app user connectors. For Google and Microsoft, each product is its own connector but shares the same sign-in. The OAuth app setup column links to each provider’s own documentation for creating the OAuth application you configure the client with.
| Provider | App user connectors | OAuth app setup |
|---|---|---|
| Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets, Google Slides | Create OAuth credentials | |
| Microsoft | Outlook, OneDrive, SharePoint, Teams, OneNote, Word, Excel, PowerPoint | Register an application |
| GitHub | GitHub | Create an OAuth app |
| GitLab | GitLab API (GitLab.com, Self-Managed, and Dedicated) | Configure GitLab as an OAuth 2.0 provider. Use a confidential application. Start with read_user, add read_api for reads, or use api for writes. |
| Slack | Slack | Installing with OAuth |
| Salesforce | Salesforce | External Client Apps |
| HubSpot | HubSpot | Working with OAuth |
| Linear | Linear | OAuth 2.0 authentication |
| Notion | Notion | Authorization (public integration required) |
| Databricks | Databricks | Authorize user access with OAuth |
| Microsoft Fabric | Microsoft Fabric | Create a Microsoft Entra app (delegated GraphQLApi.Execute.All permission required) |
| Power BI | Power BI | Register an app (delegated Dataset.Read.All and Workspace.Read.All permissions required) |
| Snowflake | Snowflake | OAuth for custom clients |
| Amazon Redshift | Amazon Redshift | Data API with trusted identity propagation, plus connector-specific AWS setup |
| Workday | Workday | OAuth 2.0 API clients (Workday sign-in required) |
Set up an app user connector
Setup happens in two steps: configure the client in the workspace, then wire the connect experience into your app.
Register and approve your OAuth app with the provider
Before you can configure the client, you (or your organization’s admin) register an OAuth application on the provider’s side and get it approved for use. This process differs from provider to provider, and each has its own requirements. For example, you might create a Salesforce External Client App, a Databricks OAuth app, a Snowflake security integration, a Google OAuth consent screen, or a Microsoft app registration. Approval can also involve extra steps such as admin consent for a tenant, app verification for sensitive scopes, or installation approval in a workspace.
Because the exact steps and any review process are owned by the provider, the authoritative instructions live in that provider’s own documentation. The OAuth app setup links in Available app user connectors point you to each provider’s guide.
Configure the client
- Open Connectors in your workspace and select the provider you want (for example Salesforce or Gmail).
- Add a client and provide the provider’s OAuth application details for App User access (for example client ID and secret, and any account or workspace URL the provider requires).
- Under Sharing, a new client is private to you by default and shows a Private label. To share it, click Share with others. Then add workspace members by email, or click Invite entire workspace. The creator can make it private again with Make private. See Who can use connections and clients for how access affects projects and collaborators.
- Link the client to the project that should use it.
Who can configure a connector follows the standard app connector access rules: on Free and Pro plans any editor can, and on Business and Enterprise plans workspace admins and owners govern availability.
Let RShift Sites use your account while building
Builder access lets RShift Sites use your own provider account while it works on a project. This helps RShift Sites inspect live schemas, test queries, and validate provider calls before it writes the integration. Builder access is available on all plans.
Ask RShift Sites to inspect your provider data
After you link the client to the project, describe what RShift Sites should inspect or test. For example:
Use my Snowflake account to list the available databases before building the data browser.Connect your account
When the Allow RShift Sites to access Snowflake card appears, select Connect and complete the provider’s OAuth flow. The connection uses your provider permissions and applies only to this project.
Revoke access when you no longer need it
Ask RShift Sites in the project chat to stop using the connection. For example:
Stop using my Snowflake account while building this project.Revoking builder access does not unlink the client from the project or disconnect anyone who uses the published app.
RShift Sites can use builder access for read operations. It asks for approval by default before an operation that can change data in the provider. Approval is decided by the kind of request the provider API uses, so some read-only operations also ask: running a SQL query against a data warehouse (for example Snowflake or Databricks) prompts for approval even when the query only reads data. Choose Always allow on the approval card to let later requests to that connector run in this project without asking.
Offline access
When you set up a client, Allow offline access is enabled by default. It lets the gateway refresh each user’s tokens in the background so they stay connected without reauthorizing every session.
Enabling or disabling Allow offline access is available on Business and Enterprise plans. On Free and Pro plans it stays enabled. The setting is fixed once the client is linked to a project, so choose it before linking. To change it later, unlink the client from all projects first.
Add the connect experience to your app
When the client is configured and linked, tell RShift Sites what you want, and it builds the in-app “Connect” flow. For example:
Let my users connect their own Gmail so the dashboard shows their inbox.Add a "Connect Salesforce" button so each signed-in user links their own account, then show their own open opportunities and let them log a call.You can start from the UI or from the project chat. The pattern is the same: configure the client in the UI, then ask RShift Sites to connect it in your app. From there, each of your users connects their own account the first time they use the feature.
Managing clients
- Users can disconnect their own account at any time, which revokes the stored tokens for that user.
- Deleting the client removes access for every user of that connector in the linked projects.
See Integration security for credential storage, rotation, outbound IP ranges, and data retention that apply to all gateway connectors.
FAQ
What is an app user connector?
An app user connector lets each end user of your published app connect their own third-party account, so your app acts on their behalf with their own permissions. It differs from a standard app connector, where you connect a single account once and every visitor shares it.
Can a user only see their own data?
Yes. Each user’s access is isolated. The gateway forwards requests using that user’s credentials and their granted scopes, so one user’s access can never be used to act as another user.
Do I need authentication in my app to use this?
Usually yes. Each sign-in is tied to a specific user, so your app needs to know who the current user is. Use built-in authentication (Cloud) or your own auth before prompting a user to connect. The exception is enterprise accounts that publish a project to their own workspace: RShift Sites derives the user’s identity through RShift Sites Auth, so no extra authentication is needed.
Are the user’s tokens ever exposed to me or my app?
No. Tokens are stored encrypted in the connector gateway and are never visible in your project, to workspace admins, or to RShift Sites while it builds your app. Your app calls the connector through the gateway, which injects credentials behind the scenes and refreshes them automatically.