Description:

The GetOrgUsers step retrieves users based on an organization structure. It accepts a process user ID, allows you to select the required organization user type, and stores the resulting user IDs in a specified Variable/Global.

This step is useful when a workflow needs to determine users dynamically from the organizational hierarchy rather than specifying individual users directly.

Usage: 

The GetOrgUsers step is typically placed after the workflow has identified a process user and before another activity that needs the corresponding organization users.

A typical workflow pattern is:

Identify Process User → GetOrgUsers → Use Retrieved User IDs

For example:

1. Obtain the process user ID.
2. Pass the ID to GetOrgUsers.
3. Select the required organization user type.
4. Store the resulting user IDs in a Variable/Global.
5. Use the Variable/Global in subsequent workflow activities.

Because the step returns user IDs rather than directly performing an assignment or notification operation, it can act as a dynamic user-resolution stage within a larger workflow.

Typical Workflow Suggestions:

Determine Users from an Organization Structure

Use GetOrgUsers when a workflow needs to identify users associated with a particular process user.

Example flow:

Process User → GetOrgUsers → Store User IDs → Continue Workflow

This avoids hard-coding individual user IDs into the workflow.

Dynamic User Assignment

Use the retrieved user IDs as input to a subsequent user or task assignment operation.

Example flow:

Identify User → GetOrgUsers → Retrieve User IDs → Assign/Route Work

This can be useful when the appropriate workflow participant depends on organizational relationships.

Organization-Based Notifications

Retrieve organization users and use the resulting IDs as the basis for subsequent notification processing.

Example flow:

Process User → GetOrgUsers → User IDs → Notification Step

This allows notifications to be determined dynamically from the organization structure.

Manager or Organizational-Level Routing

When the configured organization user type represents a specific organizational relationship, the step can identify the appropriate users for workflow routing.

Example flow:

Employee/User → GetOrgUsers → Selected Organization User Type → Route Workflow

Confirm the exact relationship represented by each available user type in the FlowWright environment.

Approval Routing

Use the step as part of an approval workflow where approval participants need to be determined from organizational information.

Example flow:

Requestor → GetOrgUsers → Resolve Users → Approval Assignment

This is especially useful when approval responsibility isn't fixed to a specific person.

Build Dynamic User Lists

Store the returned IDs in a Variable/Global and pass the result to subsequent workflow processing.

Example flow:

Process User → GetOrgUsers → User ID Variable → Process User List

This separates user discovery from user processing, making the workflow easier to maintain.

Reuse Organization Information

A workflow can retrieve the required users once and retain the result in a Variable/Global for subsequent activities.

Example flow:

GetOrgUsers → Store User IDs → Multiple Downstream Activities

This can reduce the need to repeatedly perform the same organization lookup within a workflow.

Conditional Processing

Use the True and False connections to provide different paths depending on the result of the operation.

Example flow:

GetOrgUsers

→ True: Continue with organization-based processing
→ False: Handle the alternate condition

Because the XML does not specify exactly which conditions produce each return value, validate the expected behavior in the target FlowWright environment.

User-Based Business Processes

You can incorporate this step into larger business processes where organizational relationships influence the next stage.

Example flow:

Business Request → Identify Process User → GetOrgUsers → Determine Participants → Continue Process

This provides a reusable organizational-user resolution stage.

Combine with Other User Management Steps

The output can be used with other FlowWright user-management or user-routing activities.

Example flow:

GetOrgUsers → Retrieve User IDs → User Processing Step → Continue Workflow

This allows the workflow to separate organization lookup from subsequent user operations.

Example:

We have included a sample organizational structure below for your reference.

Let’s build and execute the “GetOrgUsersDef” example to fetch the Manager ID of the user (MilanD) and the user's reporting structure to this person.         

• Create a new process definition named “GetOrgUsersDef” and open it in Designer mode. 
• Drag the "getOrgUsers, getWorkflowUserID” step to the canvas. 
• Connect the dots between the “Start” step and other 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 UserID. 
• Click the “getWorkflowUserID” step to configure the “Required” properties. Provide a name for the step, the workflow username, and a variable or global to store the UserID after execution. Click the Save button. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

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

• Click the first “getOrgUsers” step to configure the “Required” properties. Set the name to “getOrgUsers (Manager).” Provide the variable or global that contains the workflow userID from the previous step. Select “Managers” as the user type. Provide the variable or global that holds the manager user ID after execution. Click the Save button. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

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

• Click the second “getOrgUsers” step to configure the “Settings” properties. Enter “getOrgUsers (Report To Me)” as the name. Enter the variable or global that contains the workflow UserID from the previous step. Set the user type to “Reports To Me.” Enter the variable or global that holds the reportee's UserID after execution. Click the Save button. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

• The “Logging” configuration is necessary for documentation and for measuring workflow progress and the percentage complete. Configure 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. Click the process step. The process step should retrieve the user’s “Manager” and the people “ReportingTo” the user, as defined in the FlowWright Organization Structure.  

Tips:

• Provide a Valid Process User ID - The workflowUserID property is required. Make sure the Variable/Global supplied to the step contains the intended process user ID.
• Select the Correct Organization User Type - The organization user type determines which organization users the step is intended to retrieve. Select the appropriate option exposed by the FlowWright designer.
• Use a Dedicated Result Variable - Use a clearly named Variable/Global for the returned user IDs, such as: OrgUserIDs or ApproverUserIDs. This makes downstream workflow configuration easier to understand.
• Test with Known Organizational Relationships - Before deploying a workflow, test the step with users whose organizational relationships are already known. This makes it easier to verify that the selected user type produces the expected result.
• Validate the Returned Value - The XML specifies that the result is stored in a Variable/Global intended to hold user IDs, but it does not specify the exact runtime representation or formatting of multiple returned IDs. Verify the actual result format in your FlowWright environment before passing it to another step.
• Plan for the False Path - Do not leave the False connection unconsidered. Determine how the workflow should behave when the organization-user lookup does not produce the expected result.
• Avoid Assuming Specific Hierarchy Semantics - The XML identifies the functionality as organization-structure based but does not document the precise meaning of every selectable organization user type. Use the FlowWright UI and your organization's configuration to determine the appropriate selection.
• Keep User Resolution Separate from User Processing - A clean workflow design is: Resolve Users → Store IDs → Process Users.This makes the workflow easier to maintain and troubleshoot than embedding organization lookup logic throughout multiple activities.

Definition Sample:

Create a sample workflow definition to demonstrate the Get Organization Structure step.

For a basic test definition, configure:

Process User ID → Select User Type → Variable/Global for User IDs

Then connect the True and False paths to appropriate downstream activities.

When importing or copying a workflow definition between environments, verify that:

• The referenced process user exists.
• The organization structure is configured as expected.
• The selected organization user type is available.
• The destination Variable/Global exists or can be created.
• Any downstream step consuming the returned user IDs expects the same result format.

Click here to download the sample file.