Skip to content

Creating Data for Testing Workflows

Using the Test Workflow feature of the workflow builder causes the workflow to be executed, starting with the input data you provide. This is not a simulation of the workflow, so pay attention to what the workflow is configured to do, as it can result in real access changes for real identities.

To prevent this, you can take a number of steps to protect your data, such as creating test identities specifically for workflow testing. The best practice is to test your workflows in a sandbox environment, where inadvertent access chances might be less impactful.

Specifying Workflow Inputs

Each available workflow trigger provides its own set of input data to the workflow. For example, Account Aggregation Completed provides a source and its aggregation results while Identity Attributes Changed provides an identity and the old and new values of the changed attributes.

The Test Workflow page's Test Input field pre-populates with sample data to guide you on the structure of the required input. The workflow will not successfully execute with this example input, since the IDs and names for identities, sources, etc. will not match your site's data. You must replace the data with values from your site that can be processed through the configured actions.

Tip

Use search or the Identity Security Cloud APIs to retrieve the ID values for the required inputs.

If the Search interface does not display the technical IDs of your data, open the Column Chooser and make sure the ID checkbox is selected.

Creating Dummy Identity Data

Many workflow actions focus on identities such as retrieving identity data, enabling or disabling accounts, making access requests, and more. To minimize the risk of adding or removing access from real users, create dummy identities to use when testing workflows.

To create workflow test identities:

  1. Define a delimited file source for these identities.

  2. Create an identity profile for this source so it creates authoritative identities.

  3. Configure identity attribute mappings to populate the identity attributes required by your workflows for testing.

  4. Populate the source file with obvious dummy data. For example, use identity names like: Dummy Identity, Fake Manager. This minimizes the risk of these identities being mistaken for real users.

  5. Aggregate the source to create the test identities.

Creating Other System Accounts

Depending on the functions you are testing, these dummy users may need accounts or access on other systems in your enterprise. SailPoint recommends that you coordinate with administrators of those systems to create the necessary dummy accounts on those applications while adhering to your organization's security policies.

Ensure that your correlation logic will match the dummy accounts to your dummy identities. Then aggregate this test data.

Configuring Other Test Data

Your workflow testing might also require fake entitlements, roles, or access profiles. This might be because:

  • Your workflow changes attributes of these items which could impact real user access if the real ones were used in testing.
  • You only want to grant fake access items to the fake identities used in your testing.

In these cases, follow the same steps for creating real entitlements, roles, or access profiles, using artificial values that protect your real data. Like your identity names, these should use obviously fake names: Dummy Entitlement, Fake Role, Test AP1.

Best Practices

Keep security as a primary focus by following these best practices in managing your test data.

  • Minimize false data in your systems, creating only the accounts and access necessary for your test cases.
  • Keep your test data and your secure resources separate. For example, avoid granting high-security entitlements to test identities and accounts.
  • Outside of testing cycles, disable or delete the false identities and accounts in adherence to good security practices.
  • Perform workflow tests in a sandbox environment.

Having this test data in place will provide a safer way to test your workflows without disrupting your enterprise users' necessary business access.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.