Skip to content

Managing connectors

The table has one row per connector, with its name, the Type column (Native or MCP), the Authorization column (Individual, if each person connects their own account, or Automatic), its Category and its Status: On, Off, Needs setup, “Setting up…”, “Removing…” or Setup failed (automatic connectors say On, Optional or Off). At the top you can search by name or category, filter by Type, Categories or Status, and use Add to add a custom MCP server.

In each row’s ⋮ menu:

  • Turn on or Turn off the connector for everyone. Turning it off asks first: connected accounts are hidden and what uses them stops working until you turn it on again. Nothing is deleted.
  • Mode… on automatic connectors: Off (nobody can use it), Optional (each person adds it) or On (on for everyone automatically). The choice applies when you click Done.
  • Resource types… to choose what kind of resources the agent can bring in.
  • Set up app… to load your company’s credentials (below). If the connector already works with Nouter’s app, it says Own app….
  • Edit… and Remove on custom MCP servers.

When Connector requests is checked, members can ask you to turn on a connector that’s off (Ask for a connector). When there are some, they appear above the table, under N pending requests, one row per connector with how many people asked, the date of the last one and, if they said it, what they need it for. With none pending, only the Connector requests setting shows.

  • Approve turns the connector on for everyone and closes the request.
  • If you turn it on another way (Turn on in the ⋮, or by setting up its app), the request closes on its own the next time the table shows it on.
  • Dismiss asks first, and then closes it.

Either way, whoever asked gets an email; when it’s approved, the email takes them to Customize → Connectors → Discover to connect their account. If Approve is grey, the line below says why. A connector that still needs its app shows Set up instead, the same button as its row.

Google, Slack, Salesforce and GitHub use an app your company creates, so the connections are yours and not nouter’s. Until you load it, the row says Needs setup, with a Set up button, and nobody can connect it. When you save it, it moves to “Setting up…” and in about half a minute to On.

Google and GitHub may already be available with Nouter’s app: the row says so, and everyone connects their own account without you loading anything. When you open Own app… you’ll see “Everyone can connect … with Nouter’s app. There’s nothing to set up.”, with the form folded under Use your company’s app. Loading your company’s app is optional and replaces it, but everyone has to connect that connector again.

When you change a connector’s app (you load your company’s, remove it, or change the Client ID), the accounts people had connected stop working. Nobody needs to disconnect them: they disappear on their own the next time each person opens their connectors, and each one connects again.

The app’s form shows the steps for each provider and the Callback URL to paste into the provider’s app, with Copy next to it, and a Step-by-step guide link to this page. It’s always your organization’s address, the connector’s path and /oauth:

https://<your organization's address>/<connector's path>/oauth
  1. In Google Cloud, pick a project and enable the Gmail, Calendar, Tasks, Drive, Docs, Sheets and Slides APIs. If you’ll use Chat or BigQuery, enable them too (Chat with the People API). A resource whose API is missing doesn’t work for anyone, and reconnecting doesn’t fix it: Google refuses the request because of the project, not the account.
  2. Set up the OAuth consent screen as Internal, so only your organization’s accounts get in. Internal is only available with Google Workspace. Without it, choose External:
    • While the app is in Testing, only the test users you add can connect, and they have to reconnect every 7 days.
    • Once you publish it, anyone can connect after Google’s unverified-app warning, up to 100 users until Google verifies it.
  3. Create an OAuth client (Web application) and add the callback URL as an authorized redirect URI.
  4. Paste its Client ID and Client secret in Nouter and save.
  1. In api.slack.com/apps, create an app (From scratch) in your company’s Slack workspace.
  2. In OAuth & Permissions, add the callback URL under Redirect URLs.
  3. In OAuth & Permissions → User Token Scopes, add these scopes, one at a time: users:read, team:read, channels:read, channels:history, groups:read, groups:history, im:read, im:history, mpim:read, mpim:history, search:read, chat:write, reactions:write, im:write and mpim:write. The last four let the agent post with each person’s approval; if your app was set up before, add them too.
  4. In Basic Information → App Credentials, copy the Client ID and Client Secret, paste them in Nouter and save.

Create an External Client App (Setup → External Client App Manager) with OAuth, the callback URL, the Manage user data via APIs (api) and Perform requests at any time (refresh_token) scopes, and PKCE required. Leave Issue JSON Web Token (JWT)-based access tokens for named users off: with those tokens some objects, like Contact, fail. Paste its Consumer Key. The other two fields are optional:

  • Client secret, only if the app is confidential (it requires the secret for the exchange). A public app, with PKCE and no secret, works without it.
  • Login URL, only if your org signs in through its My Domain (https://<your domain>.my.salesforce.com) or is a sandbox (https://<your domain>--<sandbox>.sandbox.my.salesforce.com or https://test.salesforce.com). Left empty, https://login.salesforce.com is used.

Salesforce takes about 10 minutes to apply an app’s changes. If your app already existed with the mcp_api scope, add api: without it, Salesforce answers «Salesforce did not grant API access» when someone connects.

If the row says Available to everyone with Nouter’s app, everyone connects their GitHub account and sees the repositories of the organizations where Nouter’s app is installed. To add an organization, install the app from Organization → Git providers (Connect GitHub to your organization). If the app asks for new permissions, the organization’s admin accepts them on GitHub.

To use your company’s app instead, create an OAuth App (Settings → Developer settings → OAuth Apps) with the callback URL and paste its Client ID and a client secret. With it, the connector reaches everything each person can see, without installing anything. An OAuth App accepts a single callback URL.

The secret is stored encrypted and never shown again: the field stays as Loaded and, if you leave it empty, it’s kept. To rotate it, create the new one in the provider, paste it here and only then delete the old one.

EmDash does not use your company’s app: each person connects the site with their own EmDash user. The three fields in its form are optional and go together or not at all: they are only needed if the /_emdash of your sites is behind Cloudflare Access. In Cloudflare Zero Trust, create a service token and a Service Auth policy that includes it on the site’s /_emdash, and paste the Access host (for example cms.example.com), the token’s Client ID and its Client Secret here. Nouter sends the token only to that host, and the authorization in the browser still goes through Access with each person’s account. There is one host per organization. Without the fields, sites without Access work all the same. Saving them does not make anyone reconnect. The step by step is in Connect EmDash.

If a state or mode change fails, it goes back to the previous state and a notice appears. If a row says “Setup failed”, save it again to retry. The usual connection problems are in Connection problems.