Create a Workday Propagation Connection

Number of APIs: 13

This use case shows you how to create a propagation connection between a Workday source identity store and your PingOne directory target identity store.

A Workday propagation connection is unique in requiring a writeback of information from the target, PingOne directory, to the source, Workday. Workday is demonstrated because of its unique writeback requirement. This use case guides you in successfully creating a Workday propagation connection.

This scenario illustrates the following common operations: - Create a propagation plan. - Create a propagation store. - Create a writeback propagation store (applicable only to Workday). - Create a propagation rule. - Create a writeback propagation rule (applicable only to Workday). - Create propagation rule mappings. - Create writeback propagation rule mappings (applicable only to Workday).

Prerequisites

Get an access token from the worker application that you created in Getting Started with the PingOne APIs. To get a token from a different worker application in an alternate sandbox environment, run the token request endpoint using the client ID and client secret of your chosen worker app to authenticate the request. For more information, see GET a Worker Application Access Token.

Workflow order of operations

To create a Workday inbound propagation connection, you will need to complete the following tasks: 1. Make a POST request to /environments/{{envID}}/passwordPolicies to create a password policy for the population of users to synchronize with Workday. 2. Make a POST request to /environments/{{envID}}/populations to create a population of users to synchronize with Workday. 3. Make a POST request to /environments/{{envID}}/propagation/plans to create a Workday propagation plan. 4. Make a POST request to /environments/{{envID}}/propagation/stores to create a Workday inbound source propagation store with a type of Workday. 5. Make a POST request to /environments/{{envID}}/propagation/stores to create a Workday inbound target propagation store with a type of PingOne. 6. Make a POST request to /environments/{{envID}}/propagation/stores to create a Workday writeback source propagation store of type directory (applicable only to Workday). No separate writeback target propagation store is required, the target is the Workday inbound source propagation store. 7. Make a POST request to /environments/{{envID}}/propagation/plans/{{planID}}/rules to create a Workday propagation rule for mapping Workday attributes to PingOne attributes. 8. Make a POST request to /environments/{{envID}}/propagation/plans/{{planID}}/rules to create a Workday propagation rule for mapping directory attributes to Workday attributes (applicable only to Workday). 9. Make a POST request to /environments/{{envID}}/propagation/rules/{{ruleID}}/mappings to create a Workday inbound propagation rule mapping that associates a specific Workday attribute to a specific PingOne attribute. 0. Make a POST request to /environments/{{envID}}/propagation/plans/{{ruleID}}/rules to create a Workday writeback propagation rule mapping that associates a specific directory attribute to a specific Workday attribute (applicable only to Workday). 1. Make a GET request to /environments/{{envID}}/propagation/rules/{{ruleID}}/mappings to verify Workday inbound propagation rule mappings of attributes between Workday and PingOne. 2. Make a GET request to /environments/{{envID}}/propagation/rules/{{ruleID}}/mappings to verify Workday writeback propagation rule mappings of attributes between directory and Workday (applicable only to Workday). 3. Make a GET request to /environments/{{envID}}/propagation/rules to verify the Workday inbound propagation rule between Workday and PingOne and the Workday writeback propagation rule between directory and Workday (applicable only to Workday). 4. Make a GET request to /environments/{{envID}}/propagation/stores to verify Workday propagation stores of types Workday, PingOne, and directory. 5. Make a GET request to /environments/{{envID}}/propagation/plans to verify Workday propagation plans.

1. Step 12: Read writeback propagation rule mappings to verify GET {{apiPath}}/environments/{{envID}}/propagation/rules/{{wdWritebackRuleID}}/mappings

2. Step 1: Create a password policy for the Workday population POST {{apiPath}}/environments/{{envID}}/passwordPolicies

3. Step 2: Create a population to synchronize with Workday POST {{apiPath}}/environments/{{envID}}/populations

4. Step 3: Create a Workday inbound propagation plan POST {{apiPath}}/environments/{{envID}}/propagation/plans

5. Step 8: Create a Workday writeback propagation rule POST {{apiPath}}/environments/{{envID}}/propagation/plans/{{wdPlanID}}/rules

6. Step 9: Create a Workday inbound propagation rule mapping POST {{apiPath}}/environments/{{envID}}/propagation/rules/{{wdInboundRuleID}}/mappings

7. Step 10: Create a Workday writeback propagation rule mapping POST {{apiPath}}/environments/{{envID}}/propagation/rules/{{wdWritebackRuleID}}/mappings

8. Step 11: Read inbound propagation rule mappings to verify GET {{apiPath}}/environments/{{envID}}/propagation/rules/{{wdInboundRuleID}}/mappings

9. Step 13: Read all propagation rules to verify GET {{apiPath}}/environments/{{envID}}/propagation/rules

10. Step 14: Read all propagation stores to verify GET {{apiPath}}/environments/{{envID}}/propagation/stores