User Lifecycle at Scale: Provisioning, Offboarding and Access Reviews

When an organization has many editors, agencies and instances, adding and removing access by hand becomes a risk: people keep access after they leave, or keep a role from a project that ended. This article describes what Agility supports today for each stage of a user's lifecycle, and a pattern for joiners, movers, leavers and regular access reviews.

What is supported today

Need	Supported in Agility	How	Where it's documented
Add a person to an instance with a role	Yes	Settings > User Access > + Add User. The person receives an email with a link to set their password.	User Access
Give a group of people access to several instances	Yes, Enterprise	Add people at the organization level, put them in a Team, then give the Team a role in each instance under Settings > Team Access.	Teams
Sign in with your identity provider	Yes, Enterprise for Enterprise SSO	Enterprise SSO with SAML 2.0, OpenID Connect or WS-Federation. Anyone can also use Sign in with Microsoft.	Enterprise Single Sign-On with Agility
Assign roles from identity provider groups	No	Roles are assigned in Agility. Groups and roles in your identity provider aren't read. Mapping identity provider groups to Agility roles is on our roadmap: vote for it.	Enterprise Single Sign-On with Agility
Automatic provisioning from an identity provider (SCIM)	No	Use Teams, the Management API, or both, as described below. SCIM provisioning is on our roadmap: vote for it.	Enterprise Single Sign-On with Agility
Add, update or remove instance users by script	Yes	The Management API and SDKs list, save and delete instance users. These calls need an OAuth access token; a Personal Access Token is refused.	Management SDK - Instance & Users, .NET: Instance Users
Remove a person from an instance	Yes	Delete the user in Settings > User Access, or remove them from the Team. Removal takes effect on their next request.	User Authentication, Teams
See who has which permissions	Yes	The Permissions report lists global roles and roles on content, pages and asset folders. Reports also include an Access Report you can filter.	Roles and Permissions Matrix, Work Faster in Agility
See when people last signed in	Yes	Reports > User Activity shows last login and last activity, filtered by year and month.	Accessing Reports
A log of users added or removed, role changes and token creation	Not available today	Capture sign-in events in your identity provider, and keep your own record of access changes.	Audit Trail, Logging & SIEM Integration

Joiners

1. Create the identity first. If you use Enterprise SSO, create the person in your identity provider. Then add them in Agility before their first sign-in: Agility matches the email address from your identity provider to an existing Agility user. Entra users who use the Sign in with Microsoft button must have their UPN as their Agility email address.
2. Give access through a Team where you can (Enterprise). Add the person to the organization's Users page, then to the right Team. They get the Team's roles in every instance the Team has access to, now and later.
3. Otherwise, add them per instance in Settings > User Access with the lowest role that works. See the Roles and Permissions Matrix.
4. Add item-level permissions only where the job needs them. They add to the instance role on a specific page, content list or asset folder.

Scripting it. The Management API's save-user call adds a user to an instance or updates their roles, identified by email address. The roles you send replace the user's current roles. Run it with an OAuth sign-in, not a Personal Access Token. See .NET: Instance Users.

Movers

When someone changes job or project:

• Change the Team, not the person, if you use Teams. Remove them from the old Team and add them to the new one.
• Check for individual access. If a person has individual access to an instance, their Team access there is ignored. Remove the individual grant if the Team should control it.
• Review their item-level grants. Item-level security is set on each page, content list or asset folder, separately from the instance role. Use the Permissions report to find grants that belong to the old job.
• Check what their tokens can reach. A Personal Access Token inherits its owner's permissions, so when the person's permissions change, the token's access changes with them.

Leavers

Work through every route the person had into Agility:

• Identity provider. If you use SSO, disable the person in your identity provider. This blocks new sign-ins, but a session that is already open stays valid until it expires, so also remove their Agility access below. See User Authentication.
• Teams. Remove them from every Team in the organization.
• Instances. Delete them from Settings > User Access in each instance where they were added individually. This takes effect on their next request.
• Organization Admin. If they were an Organization Admin, contact support@agilitycms.com to remove them. See Organization FAQ's.
• Personal Access Tokens. Removing the person from an instance also stops any tokens they created from working on that instance. If an automation depended on one of their tokens, move it to a dedicated automation user. See Personal Access Tokens.
• AI assistants. The Agility MCP Server checks the user's permissions on every call, so removing their access also stops what an AI client signed in as them can do. See Governing AI Access to Agility CMS.
• Shared secrets they could see. Rotate API keys and webhook signing secrets the person had access to, as you would on any staff change. See Hosting, Security & Compliance and Verifying Signed Webhooks.
• Their work. Version history records who made each change, and versions are retained, so you keep the record of what they did.

For questions about another user's tokens, or to have a person's personal data removed, contact support@agilitycms.com.

Review access regularly

A regular review catches access that is no longer needed. Set the cadence your policies require, for example quarterly.

1. Run the Permissions report in each instance and compare it with who should have access.
2. Check User Activity for people with no recent login, and confirm they still need access.
3. Review Team membership on the organization's Teams page.
4. Look for individual grants that bypass your Teams.
5. Review automation users and their tokens. Confirm each one still has an owner and a purpose, and that its role is still the lowest that works.
6. Record the review with the date and what changed. Agility does not keep a customer-facing log of role changes, so your record is the evidence.

If you script reviews, the Management API can list the users on each instance. See Management SDK - Instance & Users.

Related articles

• Roles and Permissions Matrix
• Role Design Recipes
• Teams
• User Access
• User Authentication
• Security Review Guide
• Admin Go-Live Checklist
• The Agility Shared Responsibility Model