Merge pull request #207299 from OWinfreyATL/owinfreyATL-access-package-incompatible

Entitlement Management Access Package incompatibility freshness check

Author: BCS2022

articles/active-directory/governance/entitlement-management-access-package-incompatible.md

@@ -3,7 +3,7 @@ title: Configure separation of duties for an access package in Azure AD entitlem
 description: Learn how to configure separation of duties enforcement for requests for an access package in Azure Active Directory entitlement management.
 services: active-directory
 documentationCenter: ''
-author: owinfreyatl
+author: owinfreyATL
 manager: karenhoran
 editor: 
 ms.service: active-directory
@@ -21,9 +21,9 @@ ms.collection: M365-identity-device-management
 ---
 # Configure separation of duties checks for an access package in Azure AD entitlement management
 
-In Azure AD entitlement management, you can configure multiple policies, with different settings for each user community that will need access through an access package.  For example, employees might only need manager approval to get access to certain apps, but guests coming in from other organizations may require both a sponsor and a resource team departmental manager to approve. In a policy for users already in the directory, you can specify a particular group of users for who can request access. However, you may have a requirement to avoid a user obtaining excessive access.  To meet this requirement, you will want to further restrict who can request access, based on the access the requestor already has.
+In Azure AD entitlement management, you can configure multiple policies, with different settings for each user community that will need access through an access package.  For example, employees might only need manager approval to get access to certain apps, but guests coming in from other organizations may require both a sponsor and a resource team departmental manager to approve. In a policy for users already in the directory, you can specify a particular group of users for who can request access. However, you may have a requirement to avoid a user obtaining excessive access.  To meet this requirement, you'll want to further restrict who can request access, based on the access the requestor already has.
 
-With the separation of duties settings on an access package, you can configure that a user who is a member of a group or who already has an assignment to one access package cannot request an additional access package.
+With the separation of duties settings on an access package, you can configure that a user who is a member of a group or who already has an assignment to one access package can't request an additional access package.
 
 ![myaccess experience for attempting to request incompatible access](./media/entitlement-management-access-package-incompatible/request-prevented.png)
 
@@ -36,7 +36,7 @@ Similarly, you may have an application with two roles - **Western Sales** and **
  - the **Western Territory** access package has the **Eastern Territory** package as incompatible, and
  - the **Eastern Territory** access package has the **Western Territory** package as incompatible.
 
-If you’ve been using Microsoft Identity Manager or other on-premises identity management systems for automating access for on-premises apps, then you can integrate these systems with Azure AD entitlement management as well.  If you will be controlling access to Azure AD-integrated apps through entitlement management, and want to prevent users from having incompatible access, you can configure that an access package is incompatible with a group. That could be a group, which your on-premises identity management system sends into Azure AD through Azure AD Connect. This check ensures a user will be unable to request an access package, if that access package would give access that's incompatible with access the user has in on-premises apps.
+If you’ve been using Microsoft Identity Manager or other on-premises identity management systems for automating access for on-premises apps, then you can integrate these systems with Azure AD entitlement management as well.  If you'll be controlling access to Azure AD-integrated apps through entitlement management, and want to prevent users from having incompatible access, you can configure that an access package is incompatible with a group. That could be a group, which your on-premises identity management system sends into Azure AD through Azure AD Connect. This check ensures a user will be unable to request an access package, if that access package would give access that's incompatible with access the user has in on-premises apps.
 
 ## Prerequisites
 
@@ -53,19 +53,19 @@ Follow these steps to change the list of incompatible groups or other access pac
 
 1.	Sign in to the [Azure portal](https://portal.azure.com).
 
-1.  Click **Azure Active Directory**, and then click **Identity Governance**.
+1.  Select **Azure Active Directory**, and then select **Identity Governance**.
 
-1.	In the left menu, click **Access packages** and then open the access package which users will request.
+1.	In the left menu, select **Access packages** and then open the access package which users will request.
 
-1.	In the left menu, click **Separation of duties**.
+1.	In the left menu, select **Separation of duties**.
 
-1.  If you wish to prevent users who have another access package assignment already from requesting this access package, click on **Add access package** and select the access package that the user would already be assigned.
+1.  If you wish to prevent users who have another access package assignment already from requesting this access package, select on **Add access package** and select the access package that the user would already be assigned.
 
 
     ![configuration of incompatible access packages](./media/entitlement-management-access-package-incompatible/select-incompatible-ap.png)
 
 
-1.  If you wish to prevent users who have an existing group membership from requesting this access package, then click on **Add group** and select the group that the user would already be in.
+1.  If you wish to prevent users who have an existing group membership from requesting this access package, then select on **Add group** and select the group that the user would already be in.
 
 ### Configure incompatible access packages programmatically
 
@@ -76,47 +76,47 @@ You can also configure the groups and other access packages that are incompatibl
 
 **Prerequisite role**: Global administrator, Identity Governance administrator, User administrator, Catalog owner or Access package manager
 
-Follow these steps to view the list of other access packages that have indicated that they are incompatible with an existing access package:
+Follow these steps to view the list of other access packages that have indicated that they're incompatible with an existing access package:
 
 1.	Sign in to the [Azure portal](https://portal.azure.com).
 
-1.  Click **Azure Active Directory**, and then click **Identity Governance**.
+1.  Select **Azure Active Directory**, and then select **Identity Governance**.
 
-1.	In the left menu, click **Access packages** and then open the access package.
+1.	In the left menu, select **Access packages** and then open the access package.
 
-1.	In the left menu, click **Separation of duties**.
+1.	In the left menu, select **Separation of duties**.
 
-1. Click on **Incompatible With**.
+1. Select on **Incompatible With**.
 
 ## Identifying users who already have incompatible access to another access package
 
-If you are configuring incompatible access settings on an access package that already has users assigned to it, then any of those users who also have an assignment to the incompatible access package or groups will not be able to re-request access.
+If you're configuring incompatible access settings on an access package that already has users assigned to it, then any of those users who also have an assignment to the incompatible access package or groups won't be able to re-request access.
 
 **Prerequisite role**: Global administrator, Identity Governance administrator, User administrator, Catalog owner or Access package manager
 
 Follow these steps to view the list of users who have assignments to two access packages.
 
 1.	Sign in to the [Azure portal](https://portal.azure.com).
 
-1.  Click **Azure Active Directory**, and then click **Identity Governance**.
+1.  Select **Azure Active Directory**, and then select **Identity Governance**.
 
-1.	In the left menu, click **Access packages** and then open the access package where you will be configuring incompatible assignments.
+1.	In the left menu, select **Access packages** and then open the access package where you'll be configuring incompatible assignments.
 
-1.	In the left menu, click **Assignments**.
+1.	In the left menu, select **Assignments**.
 
 1.  In the **Status** field, ensure that **Delivered** status is selected.
 
-1.  Click the **Download** button and save the resulting CSV file as the first file with a list of assignments.
+1.  Select the **Download** button and save the resulting CSV file as the first file with a list of assignments.
 
-1.  In the navigation bar, click **Identity Governance**.
+1.  In the navigation bar, select **Identity Governance**.
 
-1.	In the left menu, click **Access packages** and then open the access package which you plan to indicate as incompatible.
+1.	In the left menu, select **Access packages** and then open the access package that you plan to indicate as incompatible.
 
-1.	In the left menu, click **Assignments**.
+1.	In the left menu, select **Assignments**.
 
 1.  In the **Status** field, ensure that the **Delivered** status is selected.
 
-1.  Click the **Download** button and save the resulting CSV file as the second file with a list of assignments.
+1.  Select the **Download** button and save the resulting CSV file as the second file with a list of assignments.
 
 1.  Use a spreadsheet program such as Excel to open the two files.
 
@@ -147,11 +147,11 @@ foreach ($w in $apa_w) { if ($null -ne $w.Target -and $null -ne $w.Target.Id -an
 
 ## Configuring multiple access packages for override scenarios
 
-If an access package has been configured as incompatible, then a user who has an assignment to that incompatible access package cannot request the access package, nor can an administrator make a new assignment that would be incompatible.
+If an access package has been configured as incompatible, then a user who has an assignment to that incompatible access package can't request the access package, nor can an administrator make a new assignment that would be incompatible.
 
-For example, if the **Production environment** access package has marked the **Development environment** package as incompatible, and a user has an assignment to the **Development environment** access package, then the access package manager for **Production environment** cannot create an assignment for that user to the **Production environment**.  In order to proceed with that assignment, the user's existing assignment to the **Development environment** access package must first be removed.
+For example, if the **Production environment** access package has marked the **Development environment** package as incompatible, and a user has an assignment to the **Development environment** access package, then the access package manager for **Production environment** can't create an assignment for that user to the **Production environment**.  In order to proceed with that assignment, the user's existing assignment to the **Development environment** access package must first be removed.
 
-If there is an exceptional situation where separation of duties rules might need to be overridden, then configuring an additional access package to capture the users who have overlapping access rights will make it clear to the approvers, reviewers, and auditors the exceptional nature of those assignments.
+If there's an exceptional situation where separation of duties rules might need to be overridden, then configuring an additional access package to capture the users who have overlapping access rights will make it clear to the approvers, reviewers, and auditors the exceptional nature of those assignments.
 
 For example, if there was a scenario that some users would need to have access to both production and deployment environments at the same time, you could create a new access package **Production and development environments**.  That access package could have as its resource roles some of the resource roles of the **Production environment** access package and some of the resource roles of the **Development environment** access package.  
 
@@ -162,7 +162,7 @@ Depending on your governance processes, that combined access package could have
  - a **direct assignments policy**, so that only an access package manager would be interacting with the access package, or
  - a **users can request access policy**, so that a user can request, with potentially an additional approval stage
 
-This policy could have as its lifecycle settings a much shorter expiration number of days than a policy on other access packages, or require more frequent access reviews, with regular oversight so that users do not retain access longer than necessary.
+This policy could have as its lifecycle settings a much shorter expiration number of days than a policy on other access packages, or require more frequent access reviews, with regular oversight so that users don't retain access longer than necessary.
 
 ## Monitor and report on access assignments
 
@@ -174,7 +174,7 @@ You can use Azure Monitor workbooks to get insights on how users have been recei
 
     ![View access package events](./media/entitlement-management-logs-and-reporting/view-events-access-package.png)
 
-1. To see if there have been changes to application role assignments for an application that were not created due to access package assignments, then you can select the workbook named *Application role assignment activity*.  If you select to omit entitlement activity, then only changes to application roles that were not made by entitlement management are shown. For example, you would see a row if a global administrator had directly assigned a user to an application role.
+1. To see if there have been changes to application role assignments for an application that weren't created due to access package assignments, then you can select the workbook named *Application role assignment activity*.  If you select to omit entitlement activity, then only changes to application roles that weren't made by entitlement management are shown. For example, you would see a row if a global administrator had directly assigned a user to an application role.
 
     ![View app role assignments](./media/entitlement-management-access-package-incompatible/workbook-ara.png)