Description:

The Get Users by Role workflow step retrieves the users assigned to a selected application role and stores the result in a specified Variable or Global variable.

The step supports:

• Selecting an application role.
• Retrieving the users assigned to that role.
• Storing the resulting value in a Variable or Global variable.
• Reusing the retrieved user information in subsequent workflow steps.
• Using role-based user information as part of workflow processing.
• Returning a True or False result for subsequent workflow processing.

Usage:

The Get Users by Role step is typically placed after a workflow has determined which application role is relevant to the current process.

The selected role is supplied to the step, and the users assigned to that role are stored in the specified Variable or Global variable.

A typical workflow pattern is:

Select Role → Get Users by Role → Use Retrieved Users

The resulting value can then be used by later workflow steps to:

• Populate Variables.
• Prepare user-related workflow data.
• Support role-based processing.
• Build notifications.
• Determine recipients for subsequent activities.
• Pass user information to another workflow step.
• Perform additional user-related processing.

The reference Search Replace String documentation follows a similar pattern: a workflow step receives prepared information, performs an operation, stores the result, and makes that result available to subsequent activities.

Typical Workflow Suggestions:

Retrieve Users Assigned to a Role

Use the step when a workflow needs the users associated with an application role.

Example:

Select Application Role → Get Users by Role → Process Users

The users assigned to the selected role are stored in the configured Variable or Global variable.

Prepare Role-Based Notifications

Use the step to retrieve users associated with a role before preparing subsequent notification processing.

Example:

Determine Role → Get Users by Role → Prepare Notification → Send Notification

This lets the workflow get role-related user information before processing notifications.

The XML confirms retrieval and storage of users but does not specifically define notification or recipient behavior. Those activities are provided by the surrounding workflow.

Retrieve Users for a Business Process

Use the step when the users assigned to a role are required during business-process execution.

Example:

Process Request → Select Role → Get Users by Role → Continue Processing

The retrieved value can be stored in a Variable and supplied to later workflow activities.

Build Role-Based Workflow Data

Use the step to obtain role membership information and retain it for later processing.

Example:

Determine Application Role → Get Users by Role → Store User Information → Process Request

This keeps role lookup separate from the business logic that consumes the resulting value.

Use a Role Selected from Workflow Data

The selected role can be determined dynamically based on information collected earlier in the workflow.

Example:

Read Request Information → Determine Role → Get Users by Role → Process Users

This pattern is useful when different requests require different role-based processing.

Store Retrieved Users for Reuse

Store the result in a meaningful Variable or Global variable when multiple downstream activities need the retrieved users.

Example:

Get Users by Role
        |
        v
  Users Variable
      /   |   \
     v    v    v
 Activity Activity Activity

Process Different Roles

Use the step as part of a workflow that needs to retrieve users associated with different application roles.

Example:

Determine Role
      |
      v
Get Users by Role
      |
      v
Process Retrieved Users

Prepare User Information for a Downstream Activity

Use the step as an intermediate activity before another workflow step requires role-related user information.

Example:

Get Users by Role → Prepare User Data → Downstream Activity

This clearly separates retrieving role membership from processing that information.

Use the False Path for Alternative Processing

Use the False return path to handle an unsuccessful or unexpected result.

Example:

Get Users by Role
     /       \
  True       False
   |           |
Continue     Log / Handle
Workflow       Issue

Confirm the exact conditions that trigger each path in the target FlowWright environment.

Establish Role-Based Processing Before a User Activity

Retrieve the users assigned to a role before continuing to a downstream user-oriented workflow activity.

Example:

Determine Responsible Role → Get Users by Role → User-Related Processing

The retrieved value can be retained in a Variable or Global for downstream use.

Reuse a Standard Role Lookup Pattern

For workflows that repeatedly need to obtain users assigned to application roles, use a consistent pattern.

Example:

Role → Get Users by Role → Users Variable → Subsequent Processing

Consistent Variable naming and role-selection practices can make larger workflows easier to maintain.

Example:

Let’s build and execute the “GetUsersForRoleDef” example.          

• Create a new process definition named “GetUsersForRoleDef” and open it in designer mode. 
• Drag a “getUsersForRole” step to the canvas. 
• Connect the dots between the “Start” step and “getUsersForRole” steps, as shown above. 
• Select the line between the steps to configure the “Connection Properties”. The default property values are “None, True, False, Error, and Evaluate”. Depending on the step’s purpose, you can configure additional values.
• Define a variable or a global to store the user's list of GUID values.
• Click the "getUsersForRole" step to configure its "Settings" properties. Provide a name for the step. Click the button to select the application roles. Provide a variable or global reference to store the user list's GUID values after execution. Click the Save button. Note: Click the "AI Predict" button to have Copilot add new process steps that match your process description. 

• Click the button to select the application roles. A pop-up window will be displayed for configuration. Use the navigation keys to select the application roles. Click the Save. 

• The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. Do this by configuring the step state and percent fields individually, as shown in the images below. Configure the “Logging” using the following properties.

• Save the process definition, create a new instance, and execute it. Render the process instance and click the process step to view its properties. When the workflow reaches the Get Users by Role step, FlowWright uses the selected application role to retrieve its assigned users. The resulting value is stored in the specified Variable or Global variable. Verify the stored value and confirm that the workflow follows the expected True or False path. The Search Replace String documentation uses the same process of saving the definition, creating and executing an instance, rendering the instance, and inspecting the step during execution.

Tips:

• Select the appropriate application role before executing the step.
• Verify that you selected the intended role, not a similar one.
• Use a meaningful Variable or Global name for the retrieved value.
• Verify that the destination Variable or Global is available before the step executes.
• Test the workflow with representative application roles.
• Verify the value stored in the Variable or Global after execution.
• Consider storing the retrieved value when it will be used by multiple subsequent activities.
• Keep role-selection logic separate from downstream business processing where practical.
• Test the workflow with a role that has assigned users.
• Test the workflow with a role that has no assigned users to understand the behavior in your environment.
• Consider connecting the False return path to appropriate error handling or alternative processing.
• Test both the True and False paths.
• Do not assume the exact format of the returned user value without verifying it in the FlowWright environment.
• Do not assume that the returned value is automatically a particular delimiter-separated list, collection, or other structure unless confirmed by the implementation.
• Do not assume how duplicate users or users assigned through different role configurations are represented unless confirmed.
• Verify application-role configuration when troubleshooting unexpected results.
• If a workflow is imported into another environment, verify the available roles and role assignments.
• Keep sensitive user information out of workflow logging where appropriate.
• Use consistent Variable naming when the same role-based user retrieval pattern is used across workflows.
• Test the workflow after changes to application roles or role assignments.
• Verify downstream activities against the actual format of the stored value before deployment.

Notes:

• The Get Users by Role step is defined in the Engine category with the internal name getusersforroleLabel: Get users assigned to the application role and store them in a variable, and display name: Get Users by Role.
• The step is implemented by FlowWright.Workflow.GetUsersForRole in FlowWright.Workflow.dll and is defined as a Process step with 2 incoming connections and 2 outgoing connections.
• The step defines two required properties:
  • roleID – Select the roles
  • variableToStoreValue – Variable/Global to store the value
• The roleID property uses the selectRoles data type, implemented by FlowWright.DataTypes.ClsSelectRoles, with the description Get roles. The result destination uses the string data type, implemented by FlowWright.DataTypes.ClsTextBox.
• The step provides two return values:
  • False
  • True

Definition Sample:

You may download the sample definition(s) from the link provided and later import them into your FlowWright Process Definition (XML file) or Form Definition (HTML file) page.

Note: Verify and complete any missing configuration after importing the sample, including:

• Application role.
• Variable or Global variable used to store the retrieved users.
• Workflow Variable references.
• Environment-specific role configuration.
• Downstream True and False workflow paths.

After verifying the configuration, save the Process Definition before execution.

Click here to download the sample file.