Using Persona Workflows to manage PingOne users, groups & populations

Overview

PingOne is Ping Identity’s cloud identity platform. It provides a user directory, single sign-on, and multi-factor authentication for workforce and customer identities. Persona’s PingOne integration connects to your PingOne environment’s Platform API so you can look up and manage users, groups, and populations directly from Persona Workflows.

This integration helps IT, Compliance, and People Ops teams manage the employee account lifecycle—looking up profiles, updating attributes, managing group membership, and disabling access during an investigation—without switching out of Persona.

Benefits

Unified User Management: Look up, create, update, and delete PingOne users directly from Persona Workflows, keeping identity operations in one place.

Faster Investigations: Disable a user’s access immediately during an investigation, then re-enable it once resolved, without leaving Persona.

Group & Population Visibility: Read a user’s group memberships, add or remove them from groups, and list groups and populations to make more informed account decisions.

Integration Features

Persona’s PingOne integration supports 12 operations across three resource types in PingOne’s Platform API:

• User management: List, create, read, update, and delete users; read and set a user’s enabled state.
• Group management: List a user’s group memberships, add or remove a user from a group, and list groups in the environment.
• Population management: List populations—PingOne’s term for a defined segment of users within an environment.

Setting up the PingOne integration

Prerequisites

To set up the PingOne integration, ensure you have:

• Admin access to a PingOne environment.
• Permission to create a Worker application and assign roles in that environment.

Setting up the PingOne credentials (PingOne side)

Persona authenticates to PingOne’s Platform API using a Worker application with the OAuth2 client credentials grant. PingOne supports two Token Endpoint Authentication Methods for this credential type—Client Secret Post and Client Secret Basic—see the FAQs for which to choose.

1. In the PingOne admin console, go to the target environment.
2. Go to Connections > Applications > + Add Application > Worker application. Give the application a name with no special characters—including parentheses in the name has been confirmed to cause a silent “Save failed. There are validation errors.” message with no indication of which field is invalid.
3. Under the application’s Configuration tab, note the Client ID, Client Secret, and Environment ID.
   ⚠️ Important: The Environment ID must match the environment the Worker application itself lives in—PingOne resolves both token issuance and the target API from this one value, so a mismatch here produces a 403 error downstream rather than a clear authentication error.
4. Set Token Endpoint Authentication Method to Client Secret Basic or Client Secret Post, matching the credential you plan to add in Persona.
5. Under the Roles tab, grant the application an Identity Data Admin role, scoped to the same environment the application lives in.
6. Enable the application using the toggle in the applications list.
   ⚠️ Important: A configured but disabled application also returns a 403 error with no other symptom.

Setting up the PingOne credentials (Persona side)

1. In the Persona Dashboard, navigate to Integrations > Marketplace and select PingOne.
2. Click + Add Credential and choose the security scheme matching the Token Endpoint Authentication Method you configured in PingOne—Client Secret Post or Client Secret Basic.
3. Enter the Client ID, Client Secret, Environment ID, and Region collected from the PingOne Worker application, then save the credential.

Using the PingOne integration in a Workflow

1. Create a new workflow, or open an existing workflow you’d like to update.
2. Add a new Action step > Integrations.
3. Select the PingOne integration and choose your PingOne credential.
4. Choose an operation (for example, Read user or List groups) and map the inputs and outputs you want to use later in the workflow.
5. Save and publish the workflow.

PingOne Operations Overview

See below for a comprehensive list of available Workflow Action steps and possible configurations for the PingOne integration, grouped by resource type.

Users

List users

Lists the users in a PingOne environment. Supports filtering with a SCIM search expression and returns results one page at a time.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression limiting which users are returned, for example email eq "person@example.com". Supported operators are eq (equals), sw (starts with), ew (ends with), and co (contains), combined with and/or. Filterable attributes include username, email, external ID, family name, given name, mobile phone, and population.
  • Page Size: Maximum number of users to return in one page (1–200).
  • Page Cursor: Cursor identifying the next page of results, taken from a previous response’s next link.

Create user

Creates a user in a PingOne environment. The user is added to the environment’s default population unless a population is supplied.

Configuration Steps:

• Provide values for required fields:
  • Username: Must be unique within the environment and is not case sensitive.
• Optionally add:
  • Email, Email Verified, Name (First/Middle/Last/Formatted/Honorific Prefix/Honorific Suffix), Address, Primary Phone, Mobile Phone, Nickname, Title, User Type, External ID, Locale, Preferred Language, Time Zone, Photo Address, Multi-Factor Authentication Enabled, Identity Provider ID, Population ID (required when the environment has no default population), and Initial Status (Active or Verification Required, with an option to suppress the verification email).

Read user

Retrieves a single user from a PingOne environment by their identifier.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to retrieve.
• Optionally add:
  • Include: Return additional group membership detail alongside the user (Group IDs or Group Names).

Update user

Updates selected attributes of a user. Only the attributes supplied are changed; omitted attributes keep their current values. Use the Set user enabled state operation to enable or disable the user.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to update.
• Optionally add:
  • Any of the attributes available on Create user (Username, Email, Name, Address, etc.) to change them.

Delete user

Deletes a user from a PingOne environment.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to delete.

Read user enabled state

Reports whether a user is currently allowed to authenticate.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to check.

Set user enabled state

Enables or disables a user. A disabled user keeps their account and group memberships but cannot authenticate—useful for disabling a user’s access during an investigation and restoring it afterward, similar to Okta’s Suspend/Unsuspend actions.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to enable or disable.
  • Enabled: Set to true to allow the user to authenticate, or false to block them.

Groups

List group memberships for user

Lists the groups a user belongs to. Each membership reports whether it was assigned directly or inherited through a nested group or a group’s user filter.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user whose group memberships are listed.
• Optionally add:
  • Expand: Return the full details of each group alongside the membership.
  • Page Size / Page Cursor: Control pagination of results.

Add user to group

Adds a user directly to a group. Administrators cannot add or remove themselves from a group that carries administrator roles.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to add to the group.
  • Group ID: Identifier of the group to add the user to.

Remove user from group

Removes a group membership that was assigned directly. Memberships inherited from a nested group or a group’s user filter cannot be removed this way; they end when the group configuration no longer applies to the user.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to remove from the group.
  • Group ID: Identifier of the group to remove the user from.

List groups

Lists the groups in a PingOne environment. Supports filtering with a SCIM search expression on group name, display name, external identifier, or population.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression, for example name eq "Verified Employees" or name sw "Contractor".
  • Page Size: Maximum number of groups to return in one page (1–1000).
  • Page Cursor: Cursor identifying the next page of results.

Populations

List populations

Lists the populations in a PingOne environment. Populations group users so that password policies and themes can be applied to them, and a population identifier is needed to create a user when the environment has no default population. See the FAQs for more on what a population is.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression—only matching an identifier with eq or a name with sw (starts with) is supported, for example name sw "Employees".
  • Page Size: Maximum number of populations to return in one page. Defaults to 250.
  • Page Cursor: Cursor identifying the next page of results.

FAQs

Should I use Client Secret Post or Client Secret Basic?

Both are standard OAuth2 client credentials authentication methods for a PingOne Worker application, and neither offers different capabilities in Persona’s integration. Persona lists Client Secret Post first because it’s the method Ping Identity’s own worker-application setup guidance recommends for client-credentials use cases like this one, but Client Secret Basic works equally well. Use whichever your systems or security team standardizes on for client-credential authentication.

What is a “population” in PingOne?

A population is PingOne’s term for a defined segment of users within an environment, used to apply password policies and branding/themes to a subset of users. Every user belongs to exactly one population; if an environment has no default population, you must supply a population ID when creating a user.

What role does the PingOne Worker application need?

The Worker application needs an Identity Data Admin role, scoped to the same environment the application itself lives in. If the role is missing, scoped to the wrong environment, or the application is disabled, PingOne returns a 403 error rather than a clearer authentication failure—so if operations are failing unexpectedly, check the application’s role assignment, environment scope, and enabled state first.