Who can configure
Configuring an app means writing views, controls, forms, tools, zones, action plans and knowledge. Two things can do that: a person signed in to the Backoffice, and a service token. This page says exactly who holds what.
The matrix as it is today
| Action | Any active member | Organization administrator | Service token |
|---|---|---|---|
| Use the assistant | Yes | Yes | No |
| Read the configuration | Yes | Yes | With config:read |
| Write the configuration | Yes | Yes | With config:write |
| Register an app or a domain | No | Yes | With provision:write |
| Mint a widget key | No | Yes | With provision:write |
| Mint or revoke a service token | No | Yes | No |
| Invite and manage users | No | Yes | No |
| Grant a domain editor | No | Yes | No |
| Connect enterprise SSO | No | Operator-assisted | No |
The row worth reading twice: any active member of the organization can already write configuration with their own sign-in. Configuration writes are gated on being an active member with an organization, not on holding the admin role. What admin gates is provisioning, credentials and people.
That is the shape of the system today, stated plainly so nobody plans around a gate that is not there. If you need configuration writing to be an administrator privilege in your organization, tell us; it is a product decision rather than a setting.
Delegating to a configurator
The common case is someone outside the organization's admin group, or an AI client acting on their behalf, doing the configuration work. They do not need an Appilot role for that.
The token is the delegation. An administrator either approves the connection on the consent screen or mints a service token in the Backoffice. Either way the credential carries exactly:
- one organization, and optionally one app inside it;
- a set of scopes (
config:read,config:write,provision:write,feedback:write); - an expiry, defaulting to 30 days.
The configurator holds that credential and nothing else. They cannot switch apps, cannot widen the scopes, cannot invite a user, and cannot see anything the token does not reach. When the work is done, the administrator revokes the connection and the next call fails. No account was shared, and no role was granted.
This is the answer to "can I let an agency configure my app without making them an admin". Yes: mint them a token, scoped to that app, with an expiry that matches the engagement.
Choosing the scopes
| Preset in the Backoffice | Scopes | Use it for |
|---|---|---|
| Inspect only | config:read | An audit, a review, a second opinion |
| Edit configuration | config:read, config:write, feedback:write | Someone doing the authoring work |
| Set up integrations | the above plus provision:write | Someone standing up a new app, domain or key |
provision:write is deliberately separate from config:write: a CI token whose
job is keeping content in sync should not also be able to claim a domain and
mint credentials.
What the configurator sees
Nothing about your organization beyond the app they were given. whoami tells
them which organization they reached, which app the credential is narrowed to,
and which scopes it holds, which is what turns a wrong token into an immediate
answer rather than an opaque failure halfway through a task.
Two role vocabularies, and which is which
They look similar and they govern different populations. Getting them mixed up is the most common confusion on this page.
Organization members
People with an Appilot account in your organization, listed under Organization Users in the Backoffice.
| Role | Assistant | Configuration | Users, apps, keys |
|---|---|---|---|
| User | Yes | Yes | No |
| Admin | Yes | Yes | Yes |
A membership is also either active, pending or rejected. A pending member has a correct password and no access: their turns are refused until an administrator approves them.
Federated identities
People who reach the assistant through your app's identity relay, listed under Widget Users. They have no Appilot account of their own and no access to the Backoffice.
| Role | Meaning |
|---|---|
| Guest | The default. Can use the assistant; your organization pays for the usage. |
| Member | Promoted; treated as one of your own for knowledge scope. |
| None | Blocked. The identity exists and its turns are refused. |
Enterprise SSO's provisioning policy chooses between Member and Guest for the identities it creates. It never grants the admin role; promote a person separately if they need it.
Domain editors
A grant, not a role. An administrator can let a non-admin member register and edit controls, forms and zones on one domain directly from the page through the extension's Editor tab. Organization administrators are implicit editors on every domain. See Domain editors.
Rotation and handoff
- Regenerate a widget key's secret when someone who held it leaves. The public key is unchanged, so the page keeps working; only your relay's environment needs the new secret.
- Revoke a service token rather than letting it expire quietly when an engagement ends. Revoked access cannot be renewed; the configurator asks for a new connection.
- Renew before expiry. A warning appears seven days ahead in the Connections filter under Service tokens.
- Remove the person from the organization to end their own sign-in. Their Appilot account survives; they simply belong to no organization of yours.