Credentials

Credentials is where the access that providers and integrations use to talk to outside systems is kept. Each secret is registered once and reused by whoever needs it.

The screen requires the Superadmin role, for the same reason as Providers: it is where the secret lives.

Why it exists

Without this screen, every integration in every workspace would ask for its own secret, and the same password would end up copied in dozens of places.

With it, the design is clear: the Organization keeps the secret; the Workspace chooses what to turn on, without ever seeing the stored value. Rotating an access becomes an edit in a single place.

Register a credential

1. Click + Credential.
2. Choose the type, according to the system it will access, and click Next.
3. Fill in the fields that type requires.
4. Click Create.

The types fall into two groups:

• SMTP and Google Drive: you fill in everything in the form itself. For SMTP, name, server, port, encryption, user and password; for Google Drive, the authentication type (Personal or Organizational), the allowed domains and the service account JSON file.
• Jira, Confluence, SharePoint and OneDrive: the form only asks for a name and description. When you click Create, you're taken to the Atlassian or Microsoft consent screen, and the credential is only created once the sign-in comes back to AUMO. Before that, the service's domains must be configured in Knowledge domains; without them, the platform warns you and stops.

The credential then becomes available to the organization's integrations, connectors and providers.

The walkthrough below uses an SMTP credential:

Edit and remove

Edit lets you change a credential's value without redoing the associations that depend on it. It is the path for password rotation or token renewal.

Remove deletes the credential. Everything that depended on it stops working, and the failure shows up at the time of use, not at the time of removal. Check the associations first.

Email credentials

The server used by the Workflows send email node is registered here, as an SMTP credential. Each workspace then picks its own sender: under Organization › Workspaces, open the workspace and, in the Credentials tab, create an email credential with a name, a sender address and the SMTP credential it uses.

This lets each team send from its own sender while reusing the same server.

Next steps

• Attach credentials to registered connections in Integrations.
• Understand where they fit in the chain in MCPs and Integrations.