Directory Data Schema
Database Fields
directory_sources
primary
Access Control uses a primary source to establish the baseline identity for a user with their name, email address, and status of contract or employment lifecycle (active or deprovisioned). This primary source is usually your single sign-on (SSO) vendor that is connected to your HR Information System (HRIS) already.
Any users that are onboarding (joiners), have job/role changes, (movers), or are offboarded (leavers) are detected during the recurring sync job and trigger audit and automation workflows.
The first source that you create is your primary source. Please choose your single sign-on (SSO) vendor unless you use a separate directory that is listed below. Be sure to create your first source using the appropriate vendor.
vendor
| API Slug | Vendor Name | Development Status |
|---|---|---|
github | GitHub | Planned |
gitlab | GitLab | Testing |
google | Testing | |
azure | Microsoft Azure | Not Planned |
microsoft | Microsoft Entra ID | Not Planned |
auth0 | Okta Customer Identity (Auth0) | Planned |
okta | Okta Workforce Identity | Testing |
salesforce | SalesForce | Planned |
slack | Slack | Planned |
slug
The shorthand alpha-dash slug snakecase string (max 55 chars) you use to uniquely identify this vendor instance.
retention_days
What: This is the retention policy for setting the number of days after a user is deprovisioned that PII metadata is stored in Access Control.
How: When fetching users from the API, users that were deprovisioned more than # days ago are not imported or synced. Any existing log records are mapped to the same user ID, however the PII data is scrubbed and replaced with a Ghost User and null values where appropriate.
Why: This solves for personally identifiable information (PII) and GDPR compliance since we do not have a business need for role-based access control (RBAC) after we have verified that a user has left the company and their access deprovisioning processes are completed and audited.
Config: The default value is set to 90 for new sources. You can modify any of your existing sources and decrease it or increase up to 1095 (3 years). It is technically possible to lower this value down to 1, however you may encounter data integrity issues with eventually consistent background API sync jobs. The lowest reasonable number should be 10 days to allow time for all deprovisioning lifecycle tasks and your organization’s internal processes to occur.
Impact: If the value is increased, the users that previously were exempt will be imported during the next sync. If the value is decreased, the users that previously were included will be archived and PII will be scrubbed. If the value is re-increased, previous users are matched to their vendor_id and their PII is restored on the existing database records. All changes are logged and will trigger event transactions for impacted users.
sync_cron_schedule
What: How often that the background job should be dispatched to sync the source data and users with the latest results in the vendor API.
When: Your primary source should be synced (ex. on the hour) before syncing secondary sources (ex. at 10 minutes past the hour) so that any new or deprovisioned users are detected based on the latest data. Otherwise, they will not be detected until the next sync cycle with the updated data. If your secondary sources do not have metadata that changes very often or is not time sensitive when it does change, you can reduce those sources down to be less frequent if desired (ex. daily or weekly).
Config: This uses cron notation that can be customized to your liking.
Seconds Minutes Hours Day-of-Month Month-Int Day-of-Week-Starting-Sunday Year
- All times are in UTC.
- An asterisk runs every available timeslot.
- Use integers in a range (ex.
2-6) or with comma separated values (2,3,4,5,6) - Use a slash to perform division. For example,
*/3in the hour time field will run every 3 hours. - Use
Lin day of the month field means the last day of the month (28th-31st). - If you want a trigger to fire on a particular day of the month (for example, the 10th), but you don’t care what day of the week that is, enter 10 in the day-of-month field, and ? in the day-of-week field.
| Cron Syntax | Frequency |
|---|---|
0 */15 * * * 2-6 * | Every 15 minutes, Monday to Friday |
0 0 * * * 2-6 * | Every hour on the hour, Monday to Friday (primary source default) |
0 10 * * * 2-6 * | Every hour at 10 minutes past the hour, Monday to Friday (secondary source default) |
0 0 */3 * * 2-6 * | Every 3 hours, Monday to Friday |
0 0 20 * * 2 * | Every Monday at 12:00pm US Pacific (20:00 UTC) |
0 0 10 * * 6 * | Every Saturday at 2:00am US Pacific (10:00 UTC) |
See more examples at crontab.guru.
sync_enabled
This provides a manual override to temporarily disable sync jobs. This is useful if you are encountering errors, have a planned data migration, or otherwise just want to freeze the data in the current point in time.
metadata
credentials
directory_dimensions
api_key
name
slug
enabled
expires_after_days
deleted_at
directory_attributes
name
slug
expires_after_days
deleted_at
directory_rules
description
expires_at
When you want to add a rule with conditions that are only valid for a short period of time, you can set the expires_at value. After the expires_at value has passed, the rule and associated conditions are automatically soft deleted, and any users that previously matched the rule’s conditions will be detached from the attribute.