Description:

The Make Users Active/Inactive workflow step changes the active status of a selected process user based on the value configured for the Mark user active property.

The step supports:

• Selecting a process user by user ID.
• Marking the selected user as active.
• Marking the selected user as inactive.
• Using a Yes/No selection to control the desired user status.
• Returning a True or False result for subsequent workflow processing.

Usage:

The Make Users Active/Inactive step typically follows a workflow that identifies a user and determines the status to apply.

The Process user id identifies the target user, while Mark user active determines whether the user should be active or inactive.

A typical workflow pattern is:

Identify User → Make Users Active/Inactive → Continue Process

The step can then be followed by activities that:

• Continue user lifecycle processing.
• Complete an onboarding process.
• Complete a termination or deactivation process.
• Send a notification.
• Record or audit the workflow operation.
• Process another user.
• Handle an alternative or error path.

For example:

Start
  ↓
Identify User
  ↓
Make Users Active/Inactive
  ├── True → Continue Process
  └── False → Handle Error

Typical Workflow Suggestions:

Activate a User After Approval

Use the step to activate a user after a user activation request has passed through the required approval process.

Example:

User Activation Request → Approval → Make Users Active/Inactive → Continue Process

Configure:

• Process user ID → ID of the selected user
• Mark user active → Yes

The subsequent workflow can continue with any activities required after the status operation.

Deactivate a User During Termination

Use the step as part of a user termination workflow when the process needs to mark the selected user inactive.

Example:

Termination Request → Process Termination Tasks → Make Users Active/Inactive → Complete Process

Configure Mark user active as No.

This places the user-status operation explicitly within the termination workflow.

Activate a User After Onboarding

A workflow can activate a user after required onboarding activities are complete.

Example:

Create User Request → Onboarding Tasks → Approval → Make Users Active/Inactive

Set Mark user active to Yes.

The workflow can then continue with post-onboarding processing.

Deactivate a User During a Suspension Process

Use the step to mark a selected user inactive as part of an approved suspension process.

Example:

Suspension Request → Review → Authorization → Make Users Active/Inactive → Record Completion

Set Mark user active to No.

This provides a clearly defined workflow stage for applying the selected status.

Reactivate a User

You can also use this step to reactivate a user who was previously made inactive.

Example:

Reactivation Request → Review → Approval → Make Users Active/Inactive → Continue Process

Set Mark user active to Yes.

The same workflow step can therefore be used for both activation and deactivation.

Apply Status Based on a Workflow Decision

Use a workflow decision to determine whether the selected user should be activated or deactivated.

Example:

Evaluate User
      ↓
   Decision
   /      \
Activate  Deactivate
   ↓         ↓
Make Users Active/Inactive
          ↓
    Continue Process

Process User Lifecycle Changes

Use the step as part of a larger user lifecycle workflow.

Example:

User Lifecycle Request → Validate Request → Approval → Make Users Active/Inactive → Complete

The Process User ID can identify the user associated with the lifecycle request.

Activate Users as Part of a Business Process

A business process may need to change a user's status after a particular business condition is satisfied.

Example:

Process Request → Validate Conditions → Approval → Make Users Active/Inactive → Continue Business Process

Set Mark user active to Yes when the workflow requires activation.

Deactivate Users After Required Tasks Are Completed

Place this step at the end of a sequence of workflow activities when user deactivation should occur only after prerequisite tasks are completed.

Example:

Process Tasks → Validate Completion → Make Users Active/Inactive → Complete

Set Mark user active to No.

This makes the status change a defined part of the workflow rather than an implicit operation.

Process Multiple User Status Changes

You can use this step repeatedly when a workflow needs to process multiple users individually.

Example:

Get User → Make Users Active/Inactive → Process Next User

Each execution can provide the appropriate Process user id and desired Yes/No status.

The XML defines the user ID as a string input, making it suitable for a workflow value that identifies the target process user.

Use the Result to Control Subsequent Processing

You can connect the True and False outputs to different workflow paths.

Example:

Make Users Active/Inactive
       /           \
    True           False
     ↓               ↓
Continue          Error Handling

As with the reference documentation, you can incorporate the False path into an alternative or error-handling route; however, verify the exact runtime meaning of the returns against the FlowWright implementation.

Example:

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

• Create a new process definition called “makeUserActiveInactiveDef” and open it in Designer mode. 
• Drag a " getWorkflowUserID, makeUserActiveInactive” 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 and UserName.
• Click the “getWorkflowUserID” step to configure its “Required” properties. Provide a name for the step, the username to fetch, and the variable or global to store the user ID 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 “makeUserActiveInactive” step to configure its “Required” properties. Provide a name for the step. Specify the variable or global that contains the user ID from the previous steps. Select “Yes” to mark the user inactive. Click the Save button. Note: Click the "AI Predict" button to have Copilot add new process steps that match your process description. 

• Alternatively, you may copy and paste the workflow User ID from the User Management page. 

• 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 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 Make Users Active/Inactive step to view its properties. When the workflow reaches the step, FlowWright uses the configured Process user id and Mark user active values to perform the configured user-status operation. The step then provides its True or False return path for subsequent workflow processing. Verify that:
  • The intended process user ID was supplied.
  • Mark user active contains the intended Yes/No value.
  • The expected workflow path is followed.
  • Any downstream processing is connected appropriately.

Tips:

• Verify that Process user ID identifies the intended FlowWright user before executing the step.
• Be especially careful when setting Mark user active, because Yes and No represent opposite user-status operations.
• Remember that Mark user active defaults to No. Review the value explicitly rather than relying on the default. 
• Avoid hard-coding a user ID when an earlier workflow activity can determine the target user dynamically.
• Use meaningful workflow variables when dynamically supplying the process user ID.
• Validate the user-selection logic before changing the status.
• Keep activation and deactivation workflow paths clear and easy to distinguish.
• Consider connecting the False path to an appropriate error-handling or alternative workflow path.
• Test both Yes and No configurations when developing a reusable workflow.
• Test the workflow with representative process user IDs before deploying it.
• Verify the selected user's status after the workflow runs.
• When processing multiple users, ensure that the correct user ID is supplied for each execution of the step.
• Keep user-status changes as explicit workflow activities when they represent an important business or administrative action.
• Document why a workflow activates or deactivates a user, particularly when the operation is part of a larger lifecycle process.
• Do not assume additional user-management behavior beyond changing the active/inactive status unless the FlowWright implementation confirms it.
• Do not assume the exact runtime semantics of the True and False returns solely from their names. The XML defines the return values but does not describe their conditions.

Notes:

• The Make Users Active/Inactive step is defined in the Users category with the internal name makeuseractiveinactive, label “Make a selected user active or inactive”, and display name “Make Users Active/Inactive.”
• The step is implemented by FlowWright.Workflow.MakeUserActiveInActive 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:
  • workflowUserID – Process user ID.
  • markActive – Mark user active. 
• The first property uses the string data type, implemented by FlowWright.DataTypes.ClsTextBox.
• The second property uses the selectYesNo data type, implemented by FlowWright.DataTypes.ClsYesNo.
• The step provides two return values:
  • False
  • True

Definition Sample:

You may download the sample definition from the link provided and later import it 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:

• Process user ID.
• Mark the user active Yes/No selection.
• Workflow Variable references.
• Environment-specific settings.
• Downstream True and False workflow paths.
• Any required logging configuration.

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

Click here to download the sample file.