After Date Time Check Permissions
This page covers the team permissions required to view, create, edit, archive, and delete an After Date Time check on a source datastore. For the full reference of user roles, see User Roles. For the canonical matrix of every team-permission-gated action, see Team Permissions Overview.
Permission Matrix
The table below shows which team permissions can perform each action on a datastore the user has access to:
| Action | Reporter | Viewer | Drafter | Author | Editor |
|---|---|---|---|---|---|
| View an After Date Time check | |||||
| Create a check as Draft | |||||
| Create a check as Active | |||||
| Edit a check while it stays Draft | |||||
| Edit an Active check, or activate a Draft | |||||
| Archive a check | |||||
| Restore an archived check as Draft | |||||
| Restore an archived check as Active | |||||
| Delete an archived check permanently |
Key Details
- Viewing is available to all team permissions, including Reporter and Viewer.
- Draft work is available from the Drafter permission upward: creating a check as Draft, editing it while it stays Draft, and restoring an archived check as Draft.
- Anything that puts a check into evaluation requires at least the Author permission: creating or activating an Active check, editing an Active check, archiving, restoring as Active, and deleting permanently.
- The same rules apply through the API. The API page lists the permission each endpoint requires.
- Admins bypass team permissions and can manage checks on every datastore in the workspace. Managers do not bypass team permissions: like Members, they need the required permission in at least one team assigned to the datastore.
Team Context
Permissions are evaluated against the datastore's team assignments. A user must have the required team permission in at least one team that the datastore belongs to. For more details on how teams work, see the Team Permissions page.
See Also
-
How It Works
The complete reference: definition, field scope, properties, evaluation flow, NULL handling, filter behavior, and coverage.
-
Anomaly Reporting
The anomaly messages the check produces, what the numbers mean, Source Records highlighting, and Custom Anomaly Description.
-
Examples
Three production scenarios with sample data, anomaly messages, and the SQL equivalent of what the check evaluates.
-
Best Practices
Guidelines for choosing the cutoff, normalizing time zones, pairing rules, and keeping the signal clean.