Schedule permissions¶
Schedules use the same access model as packages: three ordered privilege levels, and a grant that can sit either on the workspace's Schedules node or on one individual schedule.
Granting on the node covers every schedule in the workspace. Granting on a single schedule below it covers only that one. Both are configured under Access management.
What each action needs¶
| Action | Minimum level | A grant on one schedule enough? |
|---|---|---|
| View the Schedules list | Viewer | ✅ |
| Open a schedule and read it | Viewer | ✅ |
| Edit fields and save | Contributor | ✅ |
| Enable / disable from the list | Contributor | ✅ |
| Add, remove and reorder tasks | Contributor | ✅ |
| Create | Administrator | ❌ workspace Schedules node only |
| Duplicate | Administrator | ❌ — it is a create |
| Delete | Administrator | ❌ workspace Schedules node only |
| Run / Stop from Executions | Workspace Administrator | ❌ |
Being an Administrator on one schedule lets you edit that schedule — not create or delete others. That is the distinction worth carrying away.
What a read-only user sees¶
View-only access gives a read-only schedule: no Save, and no Enable, Disable, Add or Remove controls.
The row checkboxes disappear too. With read-only access the list shows no checkbox column and no header checkbox — because every action they enable is closed to you. Clicking a row still opens the schedule to read. As soon as you have edit rights on even one schedule, the checkboxes come back along with Enable and Disable.
Administrators¶
Workspace and global administrators see and do exactly what they always did. None of the gating above applies to them.
Related¶
- User permissions for packages — the same model, documented from source
- The Schedules list
- Adding tasks to a schedule
- Manage users and roles in TDP
Discussed in the community
Looking for related questions…
Didn't find your answer? Ask the community about this page — questions are answered by Timextender experts, partners and other users.