Command Actions and Access Reference
Review the full command inventory, who can run each action, and what side effect each action has.
Command availability is derived from the current workspace command payload, while final write access is enforced again by the underlying task, draft, and project mutations.
- See every command the palette can currently run.
- Know which role or record state makes each command appear.
- Understand the side effect of running each action.
Where this happens
Keep this boundary clear
- Scoped queries such as `@person`, `$project`, and `#task` narrow the main results to the matching record type, and the selected record can still open its actions menu.
- The main result list favors direct matches and high-priority actions. Secondary entity-specific actions live behind the repeated `Cmd/Ctrl+K` actions menu.
- Generic create queries such as `create`, `new`, or `add` intentionally show the primary create ladder first: task, project, team, workflow, task template, project template, and then lower-frequency create actions.
- Generic settings queries such as `set`, `sett`, `setting`, or `settings` intentionally show `Open settings` first, then other settings destinations, before unrelated records.
- Open and create actions are shown from the current command payload. Mutation actions also depend on server-side write checks at execution time.
- The actions menu now includes generated property actions for tasks and projects, including favorites, people assignment, priorities, dates, labels, project moves, and status changes.
- Saved-view results now expose owner, scope, favorite, notification, and archive actions where the current viewer is allowed to use them.
Do the work
- 1. Open the palette and match the target command directly or search for the record that should produce contextual actions.
- 2. Confirm that the action is visible for the current viewer, record state, and scope before you run it.
- 3. Run the action and let the shell invalidate the affected workspace data so the next surface reflects the mutation.
- 4. If an expected action is missing, check workspace role, team membership, project-lead status, task-creation availability, and whether the record is visible in the current command payload.
Keep this clear
- Workspace managers are workspace members whose role is `owner` or `admin`.
- Task creation is available to workspace managers and to active team leads or team members while workspace task creation is not commercially blocked.
- Task write actions and draft actions still require write access to the matched task team when the command is executed.
- Project update actions require the viewer to be a workspace manager or the current lead of the matched project when the command is executed.
- Generated secondary actions are derived from live workspace data, so assignment choices, project moves, and label actions only appear for records that are currently available in the command payload.
Access rules used by command actions
Global actions
Task actions
Draft actions
Project actions
Person actions
Team actions
View actions
Route-aware first result
Keep Going in Search and Shortcuts
Stay in the same interface and move to the next closest task in this topic when needed.
Search the Workspace
Search the workspace command palette across records, saved views, and runnable commands from any page in the shell.
Open the Command Palette
Open the command palette from the public site or workspace shell and use it as the fastest launcher.
Nearby Guides
These guides stay close to the current workflow so you can keep moving without restarting discovery.
Search the Workspace
Search the workspace command palette across records, saved views, and runnable commands from any page in the shell.
Open the Command Palette
Open the command palette from the public site or workspace shell and use it as the fastest launcher.