You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/app-provisioning/sap-successfactors-integration-reference.md
+18-34Lines changed: 18 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,7 +88,7 @@ Based on the attribute-mapping, during full sync Azure AD provisioning service s
88
88
89
89
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.
90
90
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.
*[Handling worker conversion and rehire scenario](#handling-worker-conversion-and-rehire-scenario)
142
141
*[Handling global assignment scenario](#handling-global-assignment-scenario)
143
142
*[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)
144
145
145
146
### Retrieving additional attributes
146
147
@@ -192,9 +193,18 @@ Extending this scenario:
192
193
* If you want to map *custom35* attribute from the *User* entity, then use the JSONPath `$.employmentNav.results[0].userNav.custom35`
193
194
* If you want to map *customString35* attribute from the *EmpEmployment* entity, then use the JSONPath `$.employmentNav.results[0].customString35`
194
195
195
-
### Handling worker conversion scenario
196
+
### Handling worker conversion and rehire scenario
196
197
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:
198
208
199
209
1. Open the attribute-mapping blade of your SuccessFactors provisioning app.
200
210
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
207
217
>
208
218
1. In the schema editor, press Ctrl-H key to open the find-replace control.
209
219
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.
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]`
236
220
1. In the replace text box, copy, and paste the value `$.employmentNav.results[-1:]`. This JSONPath expression returns the latest *EmpEmployment* record.
1. Click on the "replace all" option to update the schema.
238
223
1. Save the schema.
239
224
1. The above process updates all JSONPath expressions as follows:
240
225
* Old JSONPath: `$.employmentNav.results[0].jobInfoNav.results[0].departmentNav.name_localized`
241
226
* New JSONPath: `$.employmentNav.results[-1:].jobInfoNav.results[0].departmentNav.name_localized`
242
227
1. Restart provisioning.
243
228
244
-
This schema change also supports the worker conversion scenario.
245
229
246
230
### Handling global assignment scenario
247
231
@@ -257,7 +241,7 @@ To fetch attributes belonging to the standard assignment and global assignment u
257
241
1. Click on the **Download** link to save a copy of the schema before editing.
258
242
1. In the schema editor, press Ctrl-H key to open the find-replace control.
259
243
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.
261
245
1. Click on the "replace all" option to update the schema.
262
246
1. Save the schema.
263
247
1. The above process updates all JSONPath expressions as follows:
@@ -339,7 +323,7 @@ Usually the *personIdExternal* attribute value in SuccessFactors matches the *us
339
323
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.
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.
343
327
1. Save the mapping.
344
328
1. Run the provisioning job to ensure that the *userId* values flow into Azure AD.
Copy file name to clipboardExpand all lines: articles/active-directory/app-provisioning/workday-integration-reference.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -298,6 +298,10 @@ The following *Get_Workers* request queries for effective-dated updates that hap
298
298
299
299
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.
300
300
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
+
301
305
```xml
302
306
<!-- Workday incremental sync query to get new hire data effective as on hire date/first day of work -->
303
307
<!-- 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
451
455
452
456
## Handling different HR scenarios
453
457
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
+
454
462
### Support for worker conversions
455
463
456
464
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.
0 commit comments