Policy management
How access will work by the end of 2026. Reusable policies for people, groups, and API tokens. What you should do now.
What a policy is
A policy is a reusable set of access rules.
You write a policy once, then attach it to the people, groups, and API tokens that should have that access.
Today, access is a list of permissions on each person. Policies replace that list with a document you can reuse.
When it starts
Policy management starts by the end of 2026.
Until then, keep assigning permissions on each person the way you do today.
Live access does not switch over early. The date is when the new rules apply to people and API tokens.
What you should do now
Keep using permissions. You do not need to rebuild access.
Every permission on a person becomes a policy automatically. You do not move anyone by hand, and you do not start from a blank list.
If you can open the admin console, open Policies in the sidebar to see how the new screens work. That preview does not change who can sign in or what a token can do.
Live access stays the same
Permissions you set today stay in effect.
Who can open Time, approve expenses, or manage the directory still comes from the permissions on each person.
Creating or editing a policy in the preview does not grant or remove access. Use the Permissions tab on a person until policy management starts.
One policy, many attachments
Write the rule once. Attach it wherever that access belongs.
Create a policy such as Time admin or Read only. Attach that same policy to as many people as you need.
Change the policy once, and everyone attached to it gets the update. Groups work the same way. Attach a policy to a group, and everyone in the group gets it.
People, groups, and API tokens
The same policy can cover a person, a group, or an API token.
You do not keep a separate permission list for tokens. When you create a token, you attach the policies that token is allowed to use.
If you later tighten a policy, the people and the tokens attached to it follow that change.
Allow and deny
Each policy is a list of statements. A statement either allows an action or denies it.
Deny wins. If one attached policy allows Time delete and another denies it, delete is denied.
Use Allow for the work someone should do. Use Deny when a role should have broad access except for a few actions, such as deleting projects.
Services, actions, and resources
A statement names what someone can do, and where.
A service is an app, such as Time, Projects, or Governance. An action is a verb in that app: list, view, create, update, delete, or approve. A resource is the record the action applies to.
All actions in a service, or only the ones you pick
Every record, or specific records
Every service, when a policy should cover the whole organization
Pick the smallest set that still lets the work happen. AdministratorAccess is for the people who run the organization, not for a reporting integration.
Managed and custom policies
Managed policies ship with Base Assist. Custom policies are the ones you write.
AdministratorAccess and ReadOnlyAccess are managed policies. You can attach them. You cannot edit them. Duplicate a managed policy if you need a custom copy.
Custom policies are yours. You can edit, duplicate, or delete those.
Visual editor or JSON
Both describe the same policy.
Build statements with the visual editor, or edit the JSON document directly. Switch tabs to review the same Allow and Deny rules in either form.
The visual editor is enough for most policies. Use JSON when you are copying a document or reviewing a long list of actions.
Permissions become policies
Every permission you have assigned today becomes a policy.
A person who has Time admin today will have a Time admin policy attached to them when policy management starts.
You do not lose access. You do not rebuild the list. Keep the Permissions tab current until then, because that is the list that converts.
Super Admin and Admin
Those roles still open the admin console and still manage the organization.
Policies are how you grant more specific access under those roles. Super Admin can still manage people, groups, and policies.
Product admin permissions, such as Time admin, still belong on the people who run that app. Those become policies too.
If a screen is missing
If someone cannot open a screen, they do not have that access.
Ask an admin. Do not share logins to get around it.
After policy management starts, the fix is to attach the right policy, not to copy someone else's password.
Open Policies
If you can open the admin console, Policies is in the sidebar.
That list is the preview of the new experience. You can create a custom policy, duplicate a managed one, and review Allow and Deny statements.
Use it to learn the new screens. It does not change live access for people or API tokens.
Create a policy
Give it a name, then add statements.
From Policies, choose Create policy. Set a name people will recognize, such as Project contributor or Time approver.
Choose Allow or Deny for each statement
Pick a service, such as Time or Projects
Choose every action in that service, or only the ones you need
Apply the statement to every record, or to specific records
Save the policy, then open it to review the visual editor and the JSON side by side.
Attachments
This is where a policy connects to a person, a group, or an API token.
When policy management starts, you attach a policy from that policy, or from the person, group, or token that needs it.
Until then, keep assigning permissions on each person. The preview shows where attachments will live. It does not attach access yet.
Tokens use the same policies
An API token will use the same policies as a person.
You attach one or more policies to the token instead of picking a separate permission list.
A reporting integration might get ReadOnlyAccess. An integration that writes time would get a Time policy, not AdministratorAccess.
Give a token only what it needs
A token can only do what its policies allow.
If a policy denies an action, the token cannot do that action. If you later tighten the policy, the token follows the change.
If a token should stop having access, remove the policy or revoke the token. Do not leave unused tokens attached to AdministratorAccess.