PingOne Platform APIs

Create a Workday Propagation Connection

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).

  • Create a new propagation revision.

Prerequisites

Get an access token from the worker application that you created in Create an admin Worker app connection. 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, refer to Get a PingOne admin 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.

  10. 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).

  11. Make a GET request to /environments/{{envID}}/propagation/rules/{{ruleID}}/mappings to verify Workday inbound propagation rule mappings of attributes between Workday and PingOne.

  12. 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).

  13. 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).

  14. Make a GET request to /environments/{{envID}}/propagation/stores to verify Workday propagation stores of types Workday, PingOne, and directory.

  15. Make a GET request to /environments/{{envID}}/propagation/plans to verify Workday propagation plans.

  16. Make a POST request to /environments/{{envID}}/propagation/revisions to create a new propagation revision to ensure all operations are reflected in the PingOne Admin Console.

Click the Run in Postman button below to fork, or download and import, the Postman collection for this workflow to your workspace.

Run in Postman