> For the complete documentation index, see [llms.txt](https://www.cakewalk.security/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.cakewalk.security/docs/changelog/2024-product-updates.md). # 2024 {% updates format="full" %} {% update date="2024-12-20" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * A numeric field type joins the set, alongside a plain text field that accepts numbers. * Apps carry an availability date, so a record shows when access first became possible.
Fixes * A completed request in Slack showed the wrong result. * Slack messages could carry the wrong link. * Searching default apps for a user group flickered when nothing matched.
{% endupdate %} {% update date="2024-11-29" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * A declined task email carries the decline reason, so the requester knows why without asking. * Review onboarding tasks can only be reassigned to admins, which stops a review landing with someone who cannot complete it. * Users mid deactivation are excluded from HRIS sync, so a leaver is not re created while they are being removed. * Apps show a display name, a display URL and a management URL rather than one raw value doing all three jobs.
Fixes * Manually added apps and accesses carried the wrong label. * The app tab in user management broke when a search returned nothing. * Source icons on users showed the wrong tooltip.
{% endupdate %} {% update date="2024-10-31" tags="new-releases,improvements,fixes" %} ## 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](https://www.cakewalk.security/docs/human-access/how-to-guides/users-and-groups/groups-and-role-based-access-control-rbac) 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.
Improvements * Removing someone from a synced group removes the access it granted. * Work app owners are excluded from automatic deprovisioning, so a sync does not strip the person responsible for the app. * The new app email carries the compliance information a reviewer needs. * User and app counts match the underlying lists, including where a person appears twice. * Slack announces a newly added app with the detail people asked for. * Integrations declare their scope and how they communicate, which is what allows an HRIS connection to be switched between modes.
Fixes * Group membership refreshes when a synced group is converted into a Cakewalk group. * Task and request detail were missing fields the panel needed.
{% endupdate %} {% update date="2024-09-30" tags="new-releases,improvements" %} ## 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](https://www.cakewalk.security/docs/human-access/how-to-guides/auto-provisioning/how-it-works/idp-based-auto-provisioning), which is a different mechanism from the Agent Cake engine that arrived later. Both are [ways to provision an app](https://www.cakewalk.security/docs/human-access/how-to-guides/auto-provisioning/introduction/auto-provisioning-methods), 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.
Improvements * Integration import pages use an animation rather than a static image, so a long import looks like progress rather than a hang. * A user group shows its source on the global page. * Group identifiers from an identity provider are unique, which stops two syncs creating the same group twice.
{% endupdate %} {% update date="2024-08-30" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * The web app loads faster, with the main bundle split and placeholder graphics moved out of it. * A request purpose is capped at 1024 characters, so a pasted essay does not break the record. * Actions available on a user or an app are calculated in one place, which makes what you can do consistent across every view.
Fixes * A task could report that it cannot be approved when it could. * The back button behaved inconsistently across the app. * Confirming removal of a work app left the menu behind it open.
{% endupdate %} {% update date="2024-07-31" tags="new-releases,improvements,fixes" %} ## Remove access for someone else Admins, managers and app owners can file a remove access [request](https://www.cakewalk.security/docs/human-access/how-to-guides/requests) 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.
Improvements * Tasks and requests show the target user's current permission level, so an approver can see what is being changed from. * Claimable tasks in Slack carry a description of what claiming them means. * A task notification title changes when the person is no longer assigned, rather than still addressing them. * Request log tabs carry a warning badge where something needs attention. * Invited users are created in the identity provider as email invitations. * Admin actions are hidden on the app detail panel for people who are not admins.
Fixes * Claimers were not updated correctly in Slack. * Email and task titles did not match each other.
{% endupdate %} {% update date="2024-06-28" tags="new-releases,improvements,fixes" %} ## Default policies for the whole company [Policies](https://www.cakewalk.security/docs/human-access/how-to-guides/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.
Improvements * Access requests can be approved from Slack through a dedicated endpoint rather than a generic one. * App certifications are imported rather than entered by hand. * High performance endpoints for app requests, so a large list loads rather than times out. * Table columns declare their type, which makes filters behave correctly per column. * A policy cannot be saved into a state its workflow cannot run.
Fixes * The right side drawer cut off its top actions. * Multi select inputs sized themselves wrongly.
{% endupdate %} {% update date="2024-05-31" tags="new-releases,improvements,fixes" %} ## The Policy Builder This is the month access stops being decided case by case. A [policy](https://www.cakewalk.security/docs/human-access/how-to-guides/policies) 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](https://www.cakewalk.security/docs/human-access/connections-and-integrations/cakewalk-browser-extension), moved onto CSS modules with its own notification styling.
Improvements * Request titles in Slack match the web app, so the same thing is called the same name in both. * A permission level description is capped at 1024 characters. * Tables put the first column in bold, which makes a long row scannable. * The sidebar follows the new designs.
Fixes * Policy tags and chip colours were inconsistent.
{% endupdate %} {% update date="2024-04-30" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * A reminder set filter on requests. * The assignee is hidden on a completed request, where it no longer means anything. * A rotating set of loading messages, written to read like a person wrote them. * Bulk work app user operations handle larger sets. * Several slow list queries rewritten, which takes seconds off app and user pages.
Fixes * A request loop between the Slack integration and the web API. * The extension and one customer's own website interfered with each other. * Malformed data could break a response rather than being reported.
{% endupdate %} {% update date="2024-03-29" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * Indirect access shows its three sources, each explaining how the person got there. * App and access sources load for historical records, not only new ones. * The Slack app answers whenever it is mentioned, including inside a thread. * Requests show the permission being asked for on the detail page.
Fixes * An expired cache could send the Slack app to a landing page instead of the action. * Autocomplete tooltips did not appear.
{% endupdate %} {% update date="2024-02-29" tags="new-releases,improvements,fixes" %} ## 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.
Improvements * Deactivated users are excluded from the managers list. * Access start dates are recorded accurately, so a record shows when access actually began. * Duplicate users are shown with their email, so it is clear which is which. * Toast messages stay on screen for a duration that matches how much they say.
Fixes * Adding a permission level that already existed failed without explaining why. * The Slack event lock could drop an event.
{% endupdate %} {% update date="2024-01-31" tags="new-releases,improvements,fixes" %} ## Onboarding and offboarding driven by your HRIS The [joiner and leaver flow](https://www.cakewalk.security/docs/human-access/how-to-guides/users-and-groups/joiner-mover-leaver-jml) 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.
Improvements * An email when an integration breaks, rather than silence until somebody notices. * Access tracking through the browser extension is controlled by a company setting. * The Slack app carries a button that opens the relevant panel directly. * Only active review tasks are considered when reassigning, so a closed task is not handed to somebody.
Fixes * Emails were sent to people with no last access recorded. * Emails reached inactive users during a trial. * An offboarding tooltip was missing. * A broken label overlapped the text beside it on the HRIS integration screen.
{% endupdate %} {% endupdates %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.cakewalk.security/docs/changelog/2024-product-updates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.