Why Package permissions can drift
Once a user is assigned a Package, they receive a snapshot of the permission values defined at that moment. If you later update a permission's value inside the package (e.g., raise an access level), existing users do not receive the change automatically — you need to Sync it.
Similarly, if a user manually modifies a permission that was originally granted by the package (via Manage Permissions), the package detail view will flag it as Divergent.
Syncing a single permission across all users
- Open the package and find the permission row you want to align.
- Click Sync.
- The sync page lists all active package members and their current status for this permission:
- Active — already aligned, no action needed (no dropdown shown)
- Divergent — value differs, can be synced
- Manual (coincident) — manually set to the same value, can optionally be synced to change source back to package
- Not granted — was not yet provisioned, can be synced now
- Other Package — managed by another package, cannot sync from here
- Founder — never needs syncing
- For each eligible user, choose Sync or Skip.
- Confirm. Selected users are updated immediately.
Important: Syncing overwrites the existing
app_auth row for the user, regardless of whether it was originally set manually or by another source. The source is updated to package:N. This is intentional — the package takes ownership after a sync.Removing a permission from the package
- On the package detail page, click Remove on the permission row.
- The system lists all users who currently have this permission active via the package.
- For each user, choose:
- Remove Permission — deactivates their
app_authrow. - Keep Permission — leaves their individual authorization active (source remains package but the package template no longer includes it).
- Remove Permission — deactivates their
- Confirm. The permission is removed from the package definition. Future assignees will not receive it.
Removing a user from a package
- Open the package, find the user in the Active Assignees list and click their detail view ().
- Click Remove Package Assignment and confirm.
- All
app_authrows written by this package for this user are deactivated. The user appears in the Former / Disabled section of the package.
Re-assigning a Package to a previously removed user
You can re-assign a Package to a user who was previously unassigned. The system will detect that a historical record exists and reactivate it (rather than creating a duplicate row) to keep the assignment history clean.
- Click Add User inside the package.
- Search for the user.
- The system recognizes the existing record and updates it instead of inserting a new one.
- All package permissions are re-provisioned.
Note: If you had previously run a Sync that updated some permissions manually, you may need to Sync again after re-assigning to ensure the user has the latest defined values.