Okta Identity Governance release notes (Archive)

• Apps weren't unassigned from a user when their account was deactivated. (OKTA-666296)

• When reviewing a campaign, the Application last accessed date in the Review details panel didn't match the Last Login Date in the Current Assignments report. (OKTA-670107)

• Entitlement Management

  Entitlement Management offers you a simple and powerful way to ensure that users in an org have the right permissions for each resource. With Entitlement Management, you can create, store, and manage your application entitlements in Okta. Assign entitlements using a policy or individually from the Admin Console.

  The feature is integrated with Access Requests and Access Certifications to help you manage and monitor users' access to resources. You can also manage their level of access within these resources and how the access was granted from the Admin Console. Use Entitlement Management to help meet your audit and compliance requirements for professional standards like SOC2, SOX, and others. See Entitlement Management.

• Teams setting removed

  On the Access Requests Teams page, the Invite Only setting is removed. Previously, users could change the setting to False. Now Access Requests teams are always invite-only.

• Admins can now copy an existing scheduled, active, or closed campaign. See Copy campaigns. They can also modify the end date of an active campaign. See Modify campaign's end date .

• Campaign violation warnings

  A warning message now appears instead of a campaign launch failure when an admin launches a campaign that includes invalid or missing resources.

• Admin experience enhancements

  Campaigns now end when all reviewers in the campaign complete their reviews. See Campaigns.

  The following options now are available when creating or modifying a campaign:

  • Users: Only include active Okta users in this campaign: This option is only available for resource campaigns that include groups as resources. See User settings

  • Reviewers:

    1. Require justification: This option makes it mandatory for reviewers to enter a justification for their decision to approve or revoke a user's access to a resource.

    2. Disable bulk edit: This option prevents reviewers from selecting multiple reviews to approve or revoke. Reviewers can still reassign multiple reviews to another user.

  See Reviewer settings.

• When an admin used the Okta Expression Language to scope users to the dateValue profile attribute on a campaign, an warning appeared if the attribute was set to less than or equal to three days from the current date. (OKTA-645299)

• Changes to the request UI

  The UI for requests in the Access Requests web app has been updated to improve the user experience for approvers and request assignees:

  • Request details such as the request type, team, assignee, and tags are now located on the center panel instead of the right panel.

  • Actions and Activity tabs have been added to the center panel.

    • The Actions tab contains Tasks and Questions sections. See Manage tasks.

    • The Activity tab contains a log of changes or events for the request.

  • The chat has been decoupled from Activity and is now located on the right panel.

• Sync Okta groups and apps automatically

  Now applications and groups on the Resources tab sync automatically with Okta. You don't need to click Update now before using the app or group that you recently created in Okta.

• When editing a scheduled resource campaign, admins received an error and couldn't save their changes if a resource included in the campaign was deleted from Okta. (OKTA-637849)

• Disable self-review

  Admins now have the ability to disable self-review for campaigns while defining campaign reviewers. This option provides you the flexibility to allow or disallow self-reviews for each campaign. See Campaign wizard fields.

• User campaigns are now available in Production environments

  User campaigns provide you with a comprehensive view of users' access to resources. They help you tackle elevated access challenges that arise when users' relationship with the organization changes due to events such as role, department, or project change. You can configure these campaigns to only include individually assigned resources, thereby reducing the need for reviewers to review group-assigned resources governed by group membership and rules. See Campaigns.

• Past Access Requests report improvements

  The Past Access Requests report now displays requests that were approved automatically. In addition, you can also filter the report using Auto approved as a value for the Decision filter.

• Contextual information for requests

  The contextual data for actions is now available to Access requests administrators and to all members of the team that owns the request type but is unavailable to requesters. In addition, the link to Okta Workflows console is included as contextual data for the Run a workflow action.

• The Past Campaign Details report didn't always display the reviewer's name. (OKTA-630255)

• Approvers didn't receive Slack notifications when they or a request assignee completed a task assigned to them.

• The Past Campaign Details report didn't always display the reviewer's name. (OKTA-630255)

• Approvers didn't receive Slack notifications when they or a request assignee completed a task assigned to them.

• Scheduled campaigns failed to launch if the reviewer type was User's manager and a user's manager was deleted from Okta. (OKTA-628087)

• While previewing users, admins received an incorrect error message if the Okta Expression Language expression couldn't find the referenced object. (OKTA-628105)

• Admins couldn't view a campaign's details if they specified a group that should be excluded from the User campaign and then deleted the group in Okta. (OKTA-629574)

• Review details panel enhancement

  When reviewing items, the group description is now visible to reviewers (if one exists for the group). This helps reviewers make an informed decision to approve or deny user's access to the group.

• User campaigns is now available in Preview environments

  User campaigns provide you with a comprehensive view of users' access to resources. They help you tackle elevated access challenges that arise when users' relationship with the organization changes due to events such as role, department, or project change. You can configure these campaigns to only include individually assigned resources, thereby reducing the need for reviewers to review group-assigned resources governed by group membership and rules. See Campaigns.

• Okta Workflows actions for Access Requests

  Adding a Run a workflow action task in a Request Type allows requests to run a delegated flow automatically. This feature lets you use your existing Workflows connectors and flows in Access Requests to further automate requests. See Before you begin.

• Removed ability to change the requester

  Admins and request assignees can no longer change the requester after the request is submitted. They can either reject the tasks for the request or ask the requester to cancel the request.

• Just-in-time assignments

  When Request Types have conditional logic for tasks and questions, users are now assigned tasks and questions only after the prerequisite dependencies are fulfilled. This reduces confusion for users because they're only assigned tasks or questions that they can take action on.

• When reassigning review items, reviewers were unable to search for the new reviewer using their first and last name. (OKTA-443831)

• The resource's assignment date was checked at the time of remediation, which slowed the remediation process. (OKTA-582449)

• You could only have either a user or a group as the Group owner reviewer type. (OKTA-587264)

• Admins and team members could view and click the Edit draft button for Requests Types that they didn't own.

• New operator for Request Type

  The includes operator provides more flexibility in the conditional logic that references a Dropdown input type. This is useful when configuring Request Types that reference multiple resources.

• Cancel requests

  Requesters now have the flexibility to cancel a request if a team member or approver hasn't taken any action on it. They can only cancel the request from the Access Requests web app. Access Requests cancels a request if the user's access to the Access Requests web app is revoked or their status in Okta changes to suspended or deactivated. This feature improves productivity for team members and approver by reducing the incorrect requests that they need to manage.

• New System Log event for canceled requests

  The System Log now records an access.request.cancel event when a request is canceled.

• Okta Workflows failed to invoke some Access Certifications and Access Requests API endpoints. (OKTA-618561)

• Multilevel Reviews is now available in Production environments

  Use this feature to set up two levels of approval within a single campaign. You can select which review items go to the second level. You can also view the information for closed multilevel review campaigns from the Past Campaign Details and Past Campaign Summary reports.

  This feature allows you to collect decisions from different sets of relevant stakeholders to ensure accurate decisions are made for your users' access to resources. See Create campaigns.

• API support for features

  Recurring campaigns, Additional reviewer type options, Multilevel reviews, and User campaigns features are now supported by APIs.

• Supported file types

  You can now upload and download all file types in the Access Requests web app chat. When you download a file from the chat, the original name and file type are retained.

• The new name of the team was reflected only after you refreshed the team's page.

• The conditional logic for new approval tasks defaulted to is completed instead of is approved.

• User campaigns

  User campaigns provide you with a comprehensive review of users' access to resources. They help you tackle elevated access challenges that arise when users' relationship with the organization changes due to events such as, role, department, or project change. You can configure these campaigns to only include individually assigned resources, thereby reducing the need for reviewers to review group-assigned resources governed by group membership and rules. See Campaigns.

  Note: User campaigns is an Early Access feature. To learn how to enable it, see Enable self-service features.

• Campaigns on the Active, Scheduled, and Closed tabs weren't sorted in the default order of the most recent campaign first. (OKTA-607347)

• The Past Campaign Details report didn't display the reviewer name. (OKTA-613193)

• Reviewers were unable to take any action on their pending review items if the user who created the campaign was deleted from Okta. (OKTA-613929)

• Approvers didn't receive email notifications about their open tasks if they weren't a team member or request assignee, if they'd previously viewed the request, or if the request had interdependent tasks. (OKTA-608756)

• When users requested access, the response dropdown menus associated with questions didn't render properly in the Access Requests web app. (OKTA-613362)

• Some campaign pages were rendered blank if you edited a campaign after deleting or deactivating a critical resource, such as an excluded user or a reviewer group. (OKTA-594828 and OKTA-604498)

• Reviewers didn't receive email notifications if a campaign with a high volume of reviewer items had Groups as the reviewer type. (OKTA-608517)

• When filing a request in the Access Requests console, users couldn't view some Request Type questions.

• Multilevel Reviews is now available in Preview environments

  Use this feature to set up two levels of approval within a single campaign. You can select which review items go to the second level. You can also view the information for closed multilevel review campaigns from the Past Campaign Details and Past Campaign Summary reports.

  This feature allows you to collect decisions from different sets of relevant stakeholders to ensure accurate decisions are made for your users' access to resources. See Create campaigns.

• Reviewers received some email notifications with incorrect campaign due date timestamps. (OKTA-602462)

• Some users didn't receive email notifications for pending approval requests. (OKTA-604594)

• When a Request Type with multiple tasks was used for submitting requests, users received multiple duplicate messages and errors. (OKTA-591260)

• Access request admins who had a custom user type were unable to perform certain tasks in Access Requests. (OKTA-599130)

• Requests weren't marked as Done automatically when the questions and tasks were completed. (OKTA-602191)

• Multilevel Reviews

  Use this feature to set up two levels of approval within a single campaign. You can select which review items go to the second level. You can also view the information for closed multilevel review campaigns from the Past Campaign Details and Past Campaign Summary reports.

  This feature allows you to collect decisions from different sets of relevant stakeholders to ensure accurate decisions are made for your users' access to resources. See Create campaigns.

  Note: Multilevel Reviews is an Early Access feature for orgs with Identity Governance enabled. Use the Early Access Feature Manager as described in Enable self-service features to enable the feature.

• Improved UI for Settings page

  The SettingsIntegrations page in the Access Request console has been updated to improve clarity and enhance user experience. Your integrations are now grouped by their integration type.

• Impact of team deletion

  When you delete a team, all Request Types and associated requests are also deleted from the Access Requests console. You can no longer view the deleted requests in the Access Requests console. You can only view them from the Past Access Requests report.

• An error occurred when importing group owners for AD groups if queries exceeded a maximum number of entities. (OKTA-540040)

• Some customers were unable to edit or save Request Types.

• When users were assigned the access requests administrator role through group assignments, they were unable to perform admin-specific tasks. (OKTA-581692)

• Settings page update

  The Settings page user interface has been updated to improve user experience and the following tabs have been added:

  • Resources

  • Configuration lists

  • Pushed groups

  The following terms have also been updated to improve clarity and reduce confusion:

  • Resource lists synced directly from an integration are called Resources.

  • Sublists and admin-defined configuration lists are called Configuration lists.

  See Access Requests and Create a configuration list.

• Some group owners didn't receive an email notification when they were assigned an approval task in a Request Type.

• Group owner functionality for Universal Directory available in Production environments

  Admins can now view and manage the owners of a group in Okta Universal Directory. A group can have a maximum of 10 owners. This feature allows you to manage resource owners centrally when the resource ownership changes, and reduces the need to update your configurations manually. See Group ownership.

• Import group owner information from AD available in Production environments

  Admins can now import the group ownership information from AD to Okta Directory using full or incremental imports. The group owner is extracted from a managedBy attribute in AD user profile.

  This feature reduces the need to manually define group owners for AD-sourced groups that have been imported to Okta. See Import group owner from Active Directory.

Access Certifications

• Additional reviewer type options available in Preview environments

  While creating or editing an Access Certification campaign, now you can select one of the following options from the Select reviewer type dropdown menu.

  • A specific user

  • User's manager

  • Group

  • Group owner
  • Define using Okta Expression Language

  This feature allows you to select a Group and Group owner as reviewer types. As a result, you can take the following actions:

  • Assign reviews to multiple users at the same time to make review decisions when you have multiple application owners or a reviewer might be out of office.

  • Leverage the same Okta group that you use in Access Requests in Access Certifications as well. This also minimizes the need to manually update reviewers in campaigns when the reviewers change.

  See Create campaigns.

• Group owner approvals for Access Requests

  Now you can assign group owners as task assignees or approvers in a Request Type. This feature allows you to create a single Request Type instead of multiple Request Types when you need to reference groups with different group owners as approvers. See Create a request type and Group ownership.

• Change to new Request Types

  For new Request Types, you can no longer select an integration's source list as a Configuration items value for questions and conditional logic. While it's not recommended, you can still use source lists for tasks in a Request Type.

  Existing Request Types that use source lists are unaffected with this change because the system creates reusable sublists for them.

• You could configure a Request Type to use applications and groups that weren't available for your team.

• Group owner functionality for Universal Directory available in Preview environments

  Admins can now view and manage the owners of a group in Okta Universal Directory. A group can have a maximum of 10 owners. This feature allows you to manage resource owners centrally when the resource ownership changes, and reduces the need to update your configurations manually. See Group ownership.

• Import group owner information from AD available in Preview environments

  Admins can now import the group ownership information from AD to Okta Directory using full or incremental imports. The group owner is extracted from a managedBy attribute in AD user profile.

  This feature reduces the need to manually define group owners for AD-sourced groups that have been imported to Okta. See Import group owner from Active Directory.

Access Certifications

• UI enhancements

  For active campaigns, the Review details view is now available as a panel next to the review item. As well, the Reviewer and status details section has been updated and split into Reviewer details and Certification details sections. See View the progress of an active campaign.

• Some requests didn't resolve automatically when access was granted to two apps or groups at the same time.

• Some task approvers couldn't take action from the email notification because the email didn't contain the Open Tasks section.

• Sometimes second-level approvers didn't receive a Slack notification when a request was assigned to them.

• Remove Request Action menu

  Admins can no longer manually overwrite the original request using the Request Action menu in the header panel.

• UI enhancements

  For Access Certifications campaigns, the user, group, and app dropdown menus now display an icon next to each selection. In addition, the group dropdown menu now displays the number of assigned users and apps, and the app dropdown menu now displays the app status and the app ID.

  Since a user, group, or an app name isn't always unique, this enhancement provides more context to you for the resources you select. As well, these enhancements allow you to configure campaigns for the correct users, groups, and apps.

• Additional reviewer type options available in Preview environment

  While creating or editing an Access Certification campaign, now you can select one of the following options from the Select reviewer type dropdown menu.

  • A specific user

  • User's manager

  • Group

  • Group owner
  • Define using Okta Expression Language

  This feature allows you to select a Group and Group owner as reviewer types. As a result, you can take the following actions:

  • Assign reviews to multiple users at the same time to make review decisions when you have multiple application owners or a reviewer might be out of office.

  • Leverage the same Okta group that you use in Access Requests in Access Certifications as well. This also minimizes the need to manually update reviewers in campaigns when the reviewers change.

  See Create campaigns.

• View user's email address

  When adding users to a team, you can now view a user's email address in addition to their name in the Add team members dialog. This allows you to pick the correct user when you have multiple users with the same name.

• Requests submitted using email or the Access Requests Console must include a Request Type. This is to enable a smoother request approval flow. See Create requests.

• Only team members can edit requests associated with that team. This also applies to super administrators and access requests administrators.

• Team members can't remove a team or assignee from a request. They can only update the assignee.