2024
Releases, improvements and fixes in Cakewalk during 2024.
Calculated properties
A numeric property can derive its value from other properties rather than being typed in, so a figure like seat cost or headcount stays right without anyone maintaining it. Calculated values render wherever the property does, including in Slack.
At this stage a calculated property is set up by Cakewalk on request rather than in the interface. Configuring one yourself is a later step.
Properties are grouped into categories, and both categories and properties can be sorted.
A category or a calculated property that others depend on cannot be deleted out from under them.
Custom layouts
The custom fields editor gets a proper side panel, with placeholders, colour rotation on select options and a warning if you close it with unsaved changes.
Custom layouts
Apps can carry the information your own processes depend on rather than only the fields Cakewalk ships. Finance and security teams get one place that holds every app alongside the data they actually need.
Custom properties are organised into custom groups, and each property is configured rather than just created: who can see it, whether it is required, and whether it is asked for when somebody submits a request.
Property types at launch: short text, long text, number as plain, percentage or currency, person, single select and multi select.
Visibility runs per property, from Cakewalk admins only through app owners and app users to everyone.
Properties show on app general info in both the full page and the side panel, when an app is added, when its general info is edited, and while a request is being submitted.
Force a sync
An HRIS sync can be triggered on demand instead of waiting for the schedule, with a syncing flag so it is clear one is already running.
Sync user groups from your identity provider
Groups come from your identity provider rather than being rebuilt by hand. A sync groups page and an import table show what is arriving, and the data sources area is laid out around it. Google Workspace first, with Entra ID and Okta following.
A synced group is marked as such everywhere it appears, and it is read only in Cakewalk: the copy tells you to make the change in your identity provider instead. Group membership then drives access, which is what makes role based access control hold over time rather than drift.
Each app inside a synced group shows whether provisioning is configured for it.
A new standard policy, Group membership policy, covers access granted or removed because someone's groups changed. It skips the review step and goes straight to the action.
A task closed by that route records what closed it and why, rather than just disappearing.
A permission level used for provisioning cannot be deleted while the provisioning settings still point at it.
Provisioned permissions
The manage provisioning page shows which permission is actually provisioned, rather than only that provisioning exists.
Provisioning through your identity provider
An app can carry a provisioning configuration, set up per app by an admin: the source, the scope, whether provisioning and deprovisioning are on, and the default permission to grant. A Manage provisioning button sits on the app itself.
This is provisioning through your identity provider, which is a different mechanism from the Agent Cake engine that arrived later. Both are ways to provision an app, and this is the first of them.
Cakewalk tracks whether an app was assigned to someone individually or through a group, because the two unwind differently.
Provisioning state shows on the app detail view, and on the request and task panels.
Groups from your HRIS
User groups can be imported from a connected HRIS, with an initial import stage and a status for groups still being fetched.
Group creation is triggered from the import stage, so the first sync does not need a second manual step.
One action instead of two
Requests and quick admin actions stop being separate things in the interface. There is one action per job, and an admin chooses how to run it: as a request that goes through the policy, or directly.
Choosing the request route reveals the reason field, so the record captures why. Choosing the direct route does not pretend a review happened.
Unassign every permission a policy granted
A policy can be unwound in one action. Removing the policy removes the permissions it handed out, rather than leaving them behind for somebody to find later.
User status joins the quick filters on the user management table.
Remove access for someone else
Admins, managers and app owners can file a remove access request for other people. A manager can act for their reports and an app owner for the apps they own, which is what makes the promise of cutting unused accounts real rather than theoretical.
It is a row action on the user and app overviews, and it works across a multiple selection as a bulk action.
Rolling out the browser extension as a task
Getting the extension onto people's machines becomes part of the product rather than an email. Cakewalk raises an install task, sends it to Slack, and it can be declined like any other.
The extension is what surfaces the apps nobody told you about, so its rollout is the thing that determines how complete your app record is.
An install task can stand alone, without being attached to an onboarding.
Manager hierarchy
Cakewalk knows whether someone is a direct report of the current user, so an admin only sees the people they are actually responsible for.
Default policies for the whole company
Policies get a company wide layer. Set the defaults once on a global policies page and update them in bulk, rather than configuring each app as it arrives.
Editing and viewing stop being separate modes, so there is one screen for a policy instead of two.
A policy can be edited against its final design, including the archive app case.
A tasks overview
Tasks get their own page with filters, global actions and a detail view where the assignee can be changed.
Status chips carry a dot, so a state is readable at a glance rather than by reading the label.
The Policy Builder
This is the month access stops being decided case by case. A policy says who reviews a request and who carries it out, and admins build it in the product rather than asking for a config change.
A workflow has two stages. Review takes any number of steps, or none. Action takes exactly one. Reviewers and actors can be an individual, the requester's manager, the app owner, a user group, everyone holding privileged permissions in the app, admins, or general managers.
Several people can be assigned to the same step, so a task no longer stalls because one approver is out of office.
A policy applies at three levels: a company wide default per request type, a policy for one app, or a policy for a single permission level of an app.
Every change to a workflow creates a new version, and a version can carry notes explaining why.
Change permission joins Request access, Remove access and Archive app as a request type. Change app owner stops being a request and becomes a direct action.
Deleting someone who is named as an approver is blocked, with the policy that depends on them given as the reason.
Browser extension 2.0
A rebuilt browser extension, moved onto CSS modules with its own notification styling.
Permission levels everywhere they matter
Permission levels reach the views where decisions actually happen. An app detail shows the level a person holds, a user's apps show theirs, and the permission combo preselects the default rather than making somebody choose blind.
Cakewalk can tell whether the current user already has an open access request for an app, so a duplicate request is headed off before it is filed.
Apps can be added to a user with their permission level in one action.
Core apps, and apps Cakewalk manages itself
Apps gain a type, which separates the ones your company governs from the ones Cakewalk provides. Permission levels on a Cakewalk managed app cannot be edited, so the product does not let you break its own access model.
An endpoint for core apps, and default apps carry their permission levels.
Group conflicts
Where two user groups would grant conflicting access, the conflict is reported rather than silently resolved.
Permission levels become a first class thing
An app stops being all or nothing. Define the permission levels an app offers, edit them, delete the ones you do not need, and set them on the app template so every company that adds the app inherits them.
Access requests then ask for a level rather than just access, which is the difference between governing an app and recording it.
A dedicated form for adding a level, and a combo box built for choosing one.
A removal permission level, so a downgrade is a defined step rather than a delete and re add.
Levels appear on the app detail and management views.
Snooze a task
A task can be snoozed from Slack when it is not actionable yet, rather than sitting in the queue looking ignored.
Onboarding and offboarding driven by your HRIS
The joiner and leaver flow starts following the HRIS rather than a person watching it. Employee status decides who is offboarded, a removed connection cleans up the identifiers it created, and review tasks land on the leaver's manager.
Linking a user who had been ignored takes them off the ignored list, and rejecting an onboarding review puts them back on it, so the two states stay consistent instead of drifting.
Users can be marked as ignored during the import process.
A review task is closed automatically once the user it concerns is linked.
Reporting
An endpoint to generate a report, which is the first step towards getting Cakewalk data out on a schedule.