Policy, Request and Task Data Model
Cakewalk’s governance engine runs on three tightly connected objects: Policies, Requests, and Tasks. Together, they define how access is requested, approved, and fulfilled across your organization.
📜 Policies
Policies define the workflow for requests in Cakewalk. They outline the sequence of tasks and designate responsible assignees necessary to complete a request.
A policy is always tied to a request type (e.g. Add new app, Grant access, Change permissions, Remove access, Archive app).
Policies can be applied at three levels:
Global default: Applies to all apps by default for a given request type
App default: Applies to one app for a given request type
Permission-specific: Applies only to certain permission levels inside an app for a given request type
Cakewalk ships with system default policies for each request type, so new customers can get started quickly. These defaults are fully customizable. Admins can edit workflows, create new policies and assign them at the level they need.
💡 Policies are versioned and immutable once active. This ensures historical accuracy during audits.
📩 Requests
A request indicates an intent to modify your organization's app stack or a user's access within it. Each request follows an assigned policy, detailing the exact sequence of tasks and assignees needed for completion.
Each request in Cakewalk consists of two stages:
Review Stage: Designated approvers either approve or decline the request.
Action Stage: A person or Agent Cake executes the necessary action as specified by the request type (e.g., provisioning access in a Grant Access Request).
Requests are triggered automatically when a user performs an action in Cakewalk, such as requesting access, changing permissions or initiating a joiner/mover/leaver event.
Cakewalk currently supports five different request types:
Add New App Request: Introduce a completely new application to your organization's app stack.
Grant Access Request: Assign an app to a user.
Permission Change Request: Modify permissions of a user's existing access.
Remove Access Request: Remove a user's access, either voluntarily, through review or during offboarding.
Archive App Request: Remove an application from your organization.
The following components constitute a request:
Policy: Specifies the workflow and approvers.
Requester: Identifies who submitted the request.
Target App: Indicates which app is affected.
Target User: Shows whose access is affected.
Reason: Specified why a request was submitted.
Status: Tracks the request progress (e.g., In progress, Declined, Done).
💡 All requests are fully auditable, linking back to the specific policy version followed and all associated tasks.
✅ Tasks
Tasks are fundamental to executing requests, representing the necessary steps to complete a request. Each task is defined by its corresponding policy and is associated with both the request and the policy version for auditing. Completion of a request is achieved when all associated tasks are completed.
In Cakewalk, there are three types of tasks:
Review Tasks: Requires the assigned reviewers to approve or decline a request.
Action Tasks: The action the assignee needs to perform to complete request (e.g., provisioning, deprovisioning, permission changes).
Standalone Tasks: System-created for specific actions outside of a request flow (e.g., Install Browser Extension).
Each task in Cakewalk is defined by the following key attributes:
Assignee: Responsible individual, group or system agent (e.g. Agent Cake).
Origin: Always linked to a specific request and the underlying policy version.
Action: Specific task assigned to the assignee.
Decision: Result determined during task completion (e.g. Approve, Decline).
Status: Indicates task progression (e.g., In Progress, Declined, Done).
Audit Log: Records all task actions for traceability.
In your policies, you can designate these types of assignees for each task:
Admin(s): Assigns the task to all users with Admin permissions in Cakewalk.
App Owner: Assigns the task to the owner of the target app.
Custom role: Assigns the the request to a custom app role defined in your custom layouts.
Manager: Assigns the request to the manager of the target user.
Privileged User(s): Assigns the request to all users with Privileged permissions in the target app.
User Group(s): Assigns the request to all members of a selected user group.
💡Tasks are how Cakewalk operationalizes policies into practice turning abstract workflows into concrete, trackable work.
🔗 Data Flow: How They Interconnect
Policy → Request → Task → AuditPolicy defines how requests should be handled.
When a trigger occurs (e.g. user requests access), a Request is created using that policy.
The policy’s rules generate one or more Tasks — approvals, provisioning actions, etc.
Each Task completion updates the parent request’s status.
The full chain (Policy → Request → Task) is logged for auditability.
Example:
A user requests access to Figma. → Policy “Standard SaaS Access” applies. → Request is created, routed first to the user’s Manager, then to the Figma App Owner. → Two tasks are generated (one per assignee). → Once both tasks complete, the request closes.
🎯 Why This Model Matters
Scalable: Policies can apply to thousands of users without duplication.
Auditable: Every action has a clear lineage from policy → request → task.
Extensible: Future automations (Agent Cake, SCIM, webhook workflows) use this same structure.
Flexible: Supports both automated and human-driven approval paths.
Last updated
Was this helpful?