- One-time import - Import once, then manage all requests and revocations directly in AccessOwl.
- Periodic import - Update the user list on a schedule (for example, quarterly before an access review).
- Automated sync - Fully automate synchronization between AccessOwl and the application. To request this, contact AccessOwl support. We prioritize integrations based on demand.
Bringing existing access into AccessOwl
The question every rollout asks is what happens to the access people already had before AccessOwl.- Apps with a user sync integration need nothing. The sync pulls the app’s current access list, so everyone who already has access appears in AccessOwl on its own, and the list refreshes roughly every 3 hours.
- Apps without user sync need an import to seed that baseline. This covers apps with no integration at all, and apps whose integration only provisions and deprovisions. Export the current user list from the app and import it here.
An import replaces the application’s access list rather than merging with it, so import the full roster, not a subset.
How to Import a User List
1
Open the application
Go to the application and click Edit, then click Import.
2
Upload or paste your data
Upload a CSV file or copy-paste table data into the dynamic CSV importer.
3
Review and confirm
Review the imported data and confirm the import.
After you confirm an import, the imported users become the application’s current access list. Existing discoveries are removed, and the Discovered Users tab is hidden. If AccessOwl later discovers new access that is not in the imported list, the tab appears again with the new discoveries. Previously discovered users remain available in the Reports tab.
CSV Format
Your CSV always starts with the Email column. Each additional column represents one of your resources. The rows contain the permissions for that resource. Below are examples showing different permission structures.Single Resource
The simplest case. The application has one resource and each user holds one permission.Multiple Resources with Multiple Permissions
When an application has more than one resource, each resource gets its own column. A user may have permissions for some resources but not others.
Here, John has one license permission and two security group memberships. Jane only has a license and no security group assignment.
Parent Resource with Child Resources
Some applications combine a simple resource with a parent-child resource structure. In this example, the application has a Roles resource (simple) and a parent resource with two child resources: Team A and Team B. Each child resource appears as its own column, without the parent name as a prefix.
In this example, each user has a role and permissions for both Team A and Team B. Because Team A and Team B are child resources under the same parent, their permissions are handled within the same row.
Multiple Separate Resources
When an application has multiple independent resources (not parent-child), each resource gets its own column. In this example, the application has three resources: Organization Role, Project (a list of projects), and Project Role (the role within that project). Because Project and Project Role are separate resources, a user who belongs to multiple projects with different roles needs a separate row for each combination. Duplicate the user’s email for each row.
In this example, Oscar is in two projects with different roles. He is an Admin in Project Alpha and a Member in Project Beta. Because Project and Project Role are not linked as parent-child, Oscar needs two rows.