Skip to content

Commit d8d536b

Browse files
committed
Merge branch 'main' into release-cogsvcs-orchestration
2 parents 3e126c4 + de3cb0e commit d8d536b

File tree

200 files changed

+1350
-1460
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

200 files changed

+1350
-1460
lines changed

articles/active-directory/app-provisioning/sap-successfactors-integration-reference.md

Lines changed: 18 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -88,7 +88,7 @@ Based on the attribute-mapping, during full sync Azure AD provisioning service s
8888
8989
For each SuccessFactors user, the provisioning service looks for an account in the target (Azure AD/on-premises Active Directory) using the matching attribute defined in the mapping. For example: if *personIdExternal* maps to *employeeId* and is set as the matching attribute, then the provisioning service uses the *personIdExternal* value to search for the user with *employeeId* filter. If a user match is found, then it updates the target attributes. If no match is found, then it creates a new entry in the target.
9090

91-
To validate the data returned by your OData API endpoint for a specific `personIdExternal`, update the `SuccessFactorsAPIEndpoint` in the API query below with your API data center server URL and use a tool like [Postman](https://www.postman.com/downloads/) to invoke the query.
91+
To validate the data returned by your OData API endpoint for a specific `personIdExternal`, update the `SuccessFactorsAPIEndpoint` in the API query below with your API data center server URL and use a tool like [Postman](https://www.postman.com/downloads/) to invoke the query. If the "in" filter does not work, you can try the "eq" filter.
9292

9393
```
9494
https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson?$format=json&
@@ -137,10 +137,11 @@ By using JSONPath transformation, you can customize the behavior of the Azure AD
137137
This section covers how you can customize the provisioning app for the following HR scenarios:
138138
* [Retrieving additional attributes](#retrieving-additional-attributes)
139139
* [Retrieving custom attributes](#retrieving-custom-attributes)
140-
* [Handling worker conversion scenario](#handling-worker-conversion-scenario)
141-
* [Handling rehire scenario](#handling-rehire-scenario)
140+
* [Handling worker conversion and rehire scenario](#handling-worker-conversion-and-rehire-scenario)
142141
* [Handling global assignment scenario](#handling-global-assignment-scenario)
143142
* [Handling concurrent jobs scenario](#handling-concurrent-jobs-scenario)
143+
* [Retrieving position details](#retrieving-position-details)
144+
* [Provisioning users in the Onboarding module](#provisioning-users-in-the-onboarding-module)
144145

145146
### Retrieving additional attributes
146147

@@ -192,9 +193,18 @@ Extending this scenario:
192193
* If you want to map *custom35* attribute from the *User* entity, then use the JSONPath `$.employmentNav.results[0].userNav.custom35`
193194
* If you want to map *customString35* attribute from the *EmpEmployment* entity, then use the JSONPath `$.employmentNav.results[0].customString35`
194195

195-
### Handling worker conversion scenario
196+
### Handling worker conversion and rehire scenario
196197

197-
Worker conversion is the process of converting an existing full-time employee to a contractor or a contractor to full-time. In this scenario, Employee Central adds a new *EmpEmployment* entity along with a new *User* entity for the same *Person* entity. The *User* entity nested under the previous *EmpEmployment* entity is set to null. To handle this scenario so that the new employment data shows up when a conversion occurs, you can bulk update the provisioning app schema using the steps listed below:
198+
**About worker conversion scenario:** Worker conversion is the process of converting an existing full-time employee to a contractor or a contractor to full-time. In this scenario, Employee Central adds a new *EmpEmployment* entity along with a new *User* entity for the same *Person* entity. The *User* entity nested under the previous *EmpEmployment* entity is set to null.
199+
200+
**About rehire scenario:** In SuccessFactors, there are two options to process rehires:
201+
* Option 1: Create a new person profile in Employee Central
202+
* Option 2: Reuse existing person profile in Employee Central
203+
204+
If your HR process uses Option 1, then no changes are required to the provisioning schema.
205+
If your HR process uses Option 2, then Employee Central adds a new *EmpEmployment* entity along with a new *User* entity for the same *Person* entity.
206+
207+
To handle both these scenarios so that the new employment data shows up when a conversion or rehire occurs, you can bulk update the provisioning app schema using the steps listed below:
198208

199209
1. Open the attribute-mapping blade of your SuccessFactors provisioning app.
200210
1. Scroll down and click **Show advanced options**.
@@ -207,41 +217,15 @@ Worker conversion is the process of converting an existing full-time employee to
207217
>![Screenshot shows the Schema editor with Download select to save a copy of the schema.](media/sap-successfactors-integration-reference/download-schema.png#lightbox)
208218
1. In the schema editor, press Ctrl-H key to open the find-replace control.
209219
1. In the find text box, copy, and paste the value `$.employmentNav.results[0]`
210-
1. In the replace text box, copy, and paste the value `$.employmentNav.results[?(@.userNav != null)]`. Note the whitespace surrounding the `!=` operator, which is important for successful processing of the JSONPath expression.
211-
>![find-replace-conversion](media/sap-successfactors-integration-reference/find-replace-conversion-scenario.png#lightbox)
212-
1. Click on the "replace all" option to update the schema.
213-
1. Save the schema.
214-
1. The above process updates all JSONPath expressions as follows:
215-
* Old JSONPath: `$.employmentNav.results[0].jobInfoNav.results[0].departmentNav.name_localized`
216-
* New JSONPath: `$.employmentNav.results[?(@.userNav != null)].jobInfoNav.results[0].departmentNav.name_localized`
217-
1. Restart provisioning.
218-
219-
### Handling rehire scenario
220-
221-
Usually there are two options to process rehires:
222-
* Option 1: Create a new person profile in Employee Central
223-
* Option 2: Reuse existing person profile in Employee Central
224-
225-
If your HR process uses Option 1, then no changes are required to the provisioning schema.
226-
If your HR process uses Option 2, then Employee Central adds a new *EmpEmployment* entity along with a new *User* entity for the same *Person* entity. Unlike the conversion scenario, the *User* entity in the previous *EmpEmployment* entity is not set to null.
227-
228-
To handle this rehire scenario (option 2), so that the latest employment data shows up for rehire profiles, you can bulk update the provisioning app schema using the steps listed below:
229-
230-
1. Open the attribute-mapping blade of your SuccessFactors provisioning app.
231-
1. Scroll down and click **Show advanced options**.
232-
1. Click on the link **Review your schema here** to open the schema editor.
233-
1. Click on the **Download** link to save a copy of the schema before editing.
234-
1. In the schema editor, press Ctrl-H key to open the find-replace control.
235-
1. In the find text box, copy, and paste the value `$.employmentNav.results[0]`
236220
1. In the replace text box, copy, and paste the value `$.employmentNav.results[-1:]`. This JSONPath expression returns the latest *EmpEmployment* record.
221+
>![find-replace-conversion](media/sap-successfactors-integration-reference/find-replace-conversion-scenario.png#lightbox)
237222
1. Click on the "replace all" option to update the schema.
238223
1. Save the schema.
239224
1. The above process updates all JSONPath expressions as follows:
240225
* Old JSONPath: `$.employmentNav.results[0].jobInfoNav.results[0].departmentNav.name_localized`
241226
* New JSONPath: `$.employmentNav.results[-1:].jobInfoNav.results[0].departmentNav.name_localized`
242227
1. Restart provisioning.
243228

244-
This schema change also supports the worker conversion scenario.
245229

246230
### Handling global assignment scenario
247231

@@ -257,7 +241,7 @@ To fetch attributes belonging to the standard assignment and global assignment u
257241
1. Click on the **Download** link to save a copy of the schema before editing.
258242
1. In the schema editor, press Ctrl-H key to open the find-replace control.
259243
1. In the find text box, copy, and paste the value `$.employmentNav.results[0]`
260-
1. In the replace text box, copy, and paste the value `$.employmentNav.results[?(@.assignmentClass == 'ST')]`.
244+
1. In the replace text box, copy, and paste the value `$.employmentNav.results[?(@.assignmentClass == 'ST')]`. Note the whitespace surrounding the == operator, which is important for successful processing of the JSONPath expression.
261245
1. Click on the "replace all" option to update the schema.
262246
1. Save the schema.
263247
1. The above process updates all JSONPath expressions as follows:
@@ -339,7 +323,7 @@ Usually the *personIdExternal* attribute value in SuccessFactors matches the *us
339323
1. Ensure that an extensionAttribute *(extensionAttribute1-15)* in Azure AD always stores the *userId* of every worker's active employment record. This can be achieved by mapping SuccessFactors *userId* attribute to an extensionAttribute in Azure AD.
340324
> [!div class="mx-imgBorder"]
341325
> ![Inbound UserID attribute mapping](./media/sap-successfactors-integration-reference/inbound-userid-attribute-mapping.png)
342-
1. For guidance regarding JSONPath settings, refer to the section [Handling rehire scenario](#handling-rehire-scenario) to ensure the *userId* value of the active employment record flows into Azure AD.
326+
1. For guidance regarding JSONPath settings, refer to the section [Handling worker conversion and rehire scenario](#handling-worker-conversion-and-rehire-scenario) to ensure the *userId* value of the active employment record flows into Azure AD.
343327
1. Save the mapping.
344328
1. Run the provisioning job to ensure that the *userId* values flow into Azure AD.
345329
> [!NOTE]

articles/active-directory/app-provisioning/workday-integration-reference.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -298,6 +298,10 @@ The following *Get_Workers* request queries for effective-dated updates that hap
298298

299299
If any of the above queries returns a future-dated hire, then the following *Get_Workers* request is used to fetch information about a future-dated new hire. The *WID* attribute of the new hire is used to perform the lookup and the effective date is set to the date and time of hire.
300300

301+
>[!NOTE]
302+
>Future-dated hires in Workday have the Active field set to "0" and it changes to "1" on the hire date. The connector by design queries for future-hire information effective on the date of hire and that is why it always gets future hire Worker profile with Active field set to "1". This allows you to setup the Azure AD profile for future hires in advance with the all the right information pre-populated. If you'd like to delay the enabling of the Azure AD account for future hires, use the transformation function [DateDiff](functions-for-customizing-application-data.md#datediff).
303+
304+
301305
```xml
302306
<!-- Workday incremental sync query to get new hire data effective as on hire date/first day of work -->
303307
<!-- Replace version with Workday Web Services version present in your connection URL -->
@@ -451,6 +455,10 @@ To get this data, as part of the *Get_Workers* response, use the following XPATH
451455

452456
## Handling different HR scenarios
453457

458+
This section covers how you can customize the provisioning app for the following HR scenarios:
459+
* [Support for worker conversions](#support-for-worker-conversions)
460+
* [Retrieving international job assignments and secondary job details](#retrieving-international-job-assignments-and-secondary-job-details)
461+
454462
### Support for worker conversions
455463

456464
When a worker converts from employee to contingent worker or from contingent worker to employee, the Workday connector automatically detects this change and links the AD account to the active worker profile so that all AD attributes are in sync with the active worker profile. No configuration changes are required to enable this functionality. Here is the description of the provisioning behavior when a conversion happens.

articles/active-directory/enterprise-users/licensing-groups-resolve-problems.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ ms.collection: M365-identity-device-management
2222

2323
Group-based licensing in Azure Active Directory (Azure AD) introduces the concept of users in a licensing error state. In this article, we explain the reasons why users might end up in this state.
2424

25-
When you assign licenses directly to individual users, without using group-based licensing, the assignment operation might fail. For example, when you execute the PowerShell cmdlet `Set-MsolUserLicense` on a user system, the cmdlet can fail for many reasons that are related to business logic. For example, there might be an insufficient number of licenses or a conflict between two service plans that can't be assigned at the same time. The problem is immediately reported back to you.
25+
When you assign licenses directly to individual users, without using group-based licensing, the assignment operation might fail for reasons that are related to business logic. For example, there might be an insufficient number of licenses or a conflict between two service plans that can't be assigned at the same time. The problem is immediately reported back to you.
2626

2727
When you're using group-based licensing, the same errors can occur, but they happen in the background while the Azure AD service is assigning licenses. For this reason, the errors can't be communicated to you immediately. Instead, they're recorded on the user object and then reported via the administrative portal. The original intent to license the user is never lost, but it's recorded in an error state for future investigation and resolution.
2828

articles/active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ ms.service: active-directory
99
ms.subservice: msi
1010
ms.topic: how-to
1111
ms.workload: identity
12-
ms.date: 03/04/2022
12+
ms.date: 03/08/2022
1313
ms.author: barclayn
1414
ms.custom: devx-track-azurecli
1515
zone_pivot_groups: identity-mi-methods
@@ -81,13 +81,13 @@ In some environments, administrators choose to limit who can manage user-assigne
8181
1. Sign in to the [Azure portal](https://portal.azure.com).
8282
1. In the search box, enter **Managed Identities**. Under **Services**, select **Managed Identities**.
8383
1. A list of the user-assigned managed identities for your subscription is returned. Select the user-assigned managed identity that you want to manage.
84-
1. Select **Azure role assignments**, and then select **Add role assignment**.
85-
1. In the **Add role assignment** pane, configure the following values, and then select **Save**:
86-
- **Role**: The role to assign.
87-
- **Assign access to**: The resource to assign the user-assigned managed identity.
88-
- **Select**: The member to assign access.
89-
90-
![Screenshot that shows the user-assigned managed identity IAM.](media/how-manage-user-assigned-managed-identities/assign-role-screenshot-02.png)
84+
1. Select **Access control (IAM)**.
85+
1. Choose **Add role assignment**.
86+
87+
![Screenshot that shows the user-assigned managed identity access control screen](media/how-manage-user-assigned-managed-identities/role-assign.png)
88+
89+
1. In the **Add role assignment** pane, choose the role to assign and choose **Next**.
90+
1. Choose who should have the role assigned.
9191

9292
>[!NOTE]
9393
>You can find information on assigning roles to managed identities in [Assign a managed identity access to a resource by using the Azure portal](../../role-based-access-control/role-assignments-portal-managed-identity.md)
Loading
Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
title: Azure Active Directory SLA performance | Microsoft Docs
3+
description: Learn about the Azure AD SLA performance
4+
services: active-directory
5+
documentationcenter: ''
6+
author: MarkusVi
7+
manager: karenhoran
8+
editor: ''
9+
10+
ms.assetid: 9b88958d-94a2-4f4b-a18c-616f0617a24e
11+
ms.service: active-directory
12+
ms.topic: reference
13+
ms.tgt_pltfrm: na
14+
ms.workload: identity
15+
ms.subservice: report-monitor
16+
ms.date: 03/15/2022
17+
ms.author: markvi
18+
ms.reviewer: besiler
19+
20+
ms.collection: M365-identity-device-management
21+
---
22+
23+
# Azure Active Directory SLA performance
24+
25+
As an identity admin, you may need to track Azure AD's service-level agreement (SLA) performance to make sure Azure AD can support your vital apps. This article shows how the Azure AD service has performed according to the [SLA for Azure Active Directory (Azure AD)](https://azure.microsoft.com/support/legal/sla/active-directory/v1_1/).
26+
27+
You can use this article in discussions with app or business owners to help them understand the performance they can expect from Azure AD.
28+
29+
30+
## Service availability commitment
31+
32+
Microsoft offers Premium Azure AD customers the opportunity to get a service credit if Azure AD fails to meet the documented SLA. When you request a service credit, Microsoft evaluates the SLA for your specific tenant; however, this global SLA can give you an indication of the general health of Azure AD over time.
33+
34+
The SLA covers the following scenarios that are vital to businesses:
35+
36+
- **User authentication:** Users are able to login to the Azure Active Directory service.
37+
38+
- **App access:** Azure Active Directory successfully emits the authentication and authorization tokens required for users to log into applications connected to the service.
39+
40+
For full details on SLA coverage and instructions on requesting a service credit, see the [SLA for Azure Active Directory (Azure AD)](https://azure.microsoft.com/support/legal/sla/active-directory/v1_1/).
41+
42+
43+
## No planned downtime
44+
45+
You rely on Azure AD to provide identity and access management for your vital systems. To ensure Azure AD is available when business operations require it, Microsoft does not plan downtime for Azure AD system maintenance. Instead, maintenance is performed as the service runs, without customer impact.
46+
47+
## Recent worldwide SLA performance
48+
49+
To help you plan for moving workloads to Azure AD, we publish past SLA performance. These numbers show the level at which Azure AD met the requirements in the [SLA for Azure Active Directory (Azure AD)](https://azure.microsoft.com/support/legal/sla/active-directory/v1_1/), for all tenants.
50+
51+
For each month, we truncate the SLA attainment at three places after the decimal. Numbers are not rounded up, so actual SLA attainment is higher than indicated.
52+
53+
54+
| Month | 2021 | 2022 |
55+
| --- | --- | --- |
56+
| January | | 99.999% |
57+
| February | 99.999% | 99.999% |
58+
| March | 99.568% | |
59+
| April | 99.999% | |
60+
| May | 99.999% | |
61+
| June | 99.999% | |
62+
| July | 99.999% | |
63+
| August | 99.999% | |
64+
| September | 99.999% | |
65+
| October | 99.999% | |
66+
| November | 99.998% | |
67+
| December | 99.978% | |
68+
69+
70+
71+
### How is Azure AD SLA measured?
72+
73+
The Azure AD SLA is measured in a way that reflects customer authentication experience, rather than simply reporting on whether the system is available to outside connections. This means that the calculation is based on whether:
74+
75+
- Users can authenticate
76+
- Azure AD successfully issues tokens for target apps after authentication
77+
78+
The numbers above are a global total of Azure AD authentications across all customers and geographies.
79+
80+
81+
## Incident history
82+
83+
All incidents that seriously impact Azure AD performance are documented in the [Azure status history](https://status.azure.com/status/history/). Not all events documented in Azure status history are serious enough to cause Azure AD to go below its SLA. You can view information about the impact of incidents, as well as a root cause analysis of what caused the incident and what steps Microsoft took to prevent future incidents.
84+
85+
86+
87+
88+
## Next steps
89+
90+
* [Azure AD reports overview](overview-reports.md)
91+
* [Programmatic access to Azure AD reports](concept-reporting-api.md)
92+
* [Azure Active Directory risk detections](../identity-protection/overview-identity-protection.md)

articles/active-directory/reports-monitoring/toc.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -104,6 +104,8 @@
104104
- name: Reference
105105
expanded: true
106106
items:
107+
- name: Azure Active Directory SLA performance
108+
href: reference-azure-ad-sla-performance.md
107109
- name: Basic info in the sign-in logs
108110
href: reference-basic-info-sign-in-logs.md
109111
- name: Azure AD PowerShell cmdlets for reporting

0 commit comments

Comments
 (0)