Create Flow

This document explains how to create workflows on Monosign. It covers workflow process. Before you continue, it is better to start with understanding how workflows are needed and why workflows are important.

Permitted users are allowed to create Flow by clicking “Add New“ button on the Flows list page.

In MonoSign, the workflow creation step consists of three standard sections.

1. Overview

Please note that at least one policy should be created on the “Policies“ page. Therefore, flow manager can set a policy who is allowed to start the workflow directly.

If there is no policy created for the workflow, please create a generic type policy by reading this documentation.

Documentation:

2. Flow

The Flow section is where you design and configure the actual workflow steps. In this area, you define how the workflow operates from start to finish. In Monosign, flow typically includes:

1. Approval

This action creates an approval task within the workflow. It is typically used when a request requires validation by a manager, system owner, or security team.

What it does:

• Sends an approval task to assigned approvers

• Waits for a decision (Approve / Reject)

• Continues the workflow based on the approver’s decision

Common use cases:

• Access request approval

• User creation or privilege assignment validation

• Account termination approval

Approval action consists of three standard sections.

Section	Description
General	The Overview section is where you define the basic information and settings of the workflow.
Approver	The Approver section is where you define who will approve the previous step in the workflow. Manager Approval Select this option if the previous step must be approved by the requestor’s manager. You cannot use Manager Approval together with Rule-Based Approval. Starter Approval Select this option if the previous step should be approved by the user who initiated the request (the starter). By Rule Choose this option if the previous step must be approved according to predefined rules, such as user groups, user attributes, or other conditions. This option allows you to assign a set of users (e.g., a team) as approvers based on a rule.
Actions	The Actions section defines what will happen when the approval step is assigned to a user or multiple users. You can send a notification to the approvers when the approval step is assigned to them. For example, an informational email can be sent to the selected approver(s). You can use a system content for sending notification to approver/approvers. You can find the contents on System → Contents page.

2. Form

This step displays a form to the user or an administrator to collect necessary information.

What it does:

• Presents customizable fields (text, dropdown, number, checkbox, etc.)

• Collects input required by later steps

• Stores form responses as variables that can be reused in the workflow

Common use cases:

• Request justification form

• Collecting user details (department, role, email, etc.)

• Multi-step onboarding forms

3. HTTP (Web) Request

This action sends an HTTP(S) request to an external system or API.

What it does:

• Supports methods like GET, POST, PUT, DELETE

• Sends headers, query parameters, and JSON/XML body

• Reads the response and stores the returned data as workflow variables

Common use cases:

• Creating or updating users in external systems

• Integrating with HR, ticketing, or CRM systems

• Triggering automation scripts or webhooks

4. Code

This action allows writing custom logic using supported scripting languages (C#).

What it does:

• Performs advanced logic or calculations (Example: Getting user or manager information based on the employee id comes from HR.)

• Manipulates variables

• Builds dynamic data to be used in other steps

• Implements custom integration logic if needed

Common use cases:

• Formatting or validating data

• Conditional API payload creation

• Parsing API responses

• Custom business logic

5. Branch

This action enables conditional workflow branching.

What it does:

• Evaluates a condition (e.g., “if department = IT”)

• Directs the flow to different paths based on the result

• Supports multiple branches and fallback paths

Common use cases:

• Different approval chains per department

• Different onboarding tasks for contractors vs. employees

• Assigning access levels based on job role

6. Notification

This action sends a notification to users or administrators or spesific users based on a policy or a rule.

What it does:

• Sends an email, SMS, or in-app notification

• Can include dynamic content using workflow variables (e.g., username, request ID)

• Notifies relevant stakeholders about workflow status

Common use cases:

• Informing users about approval decisions

• Sending confirmation once a task is completed

• Alerting admins when an error occurs or manual action is needed

Example Flows

1. Access Replacement on End Applications

The workflow is used to manage and update user access on end applications using the MonoSync solution, it performs permission updates on target systems according to the access rights of other users.

Steps

1. Get Enforcement List (Code) and Get Systems (Code) - Parallel

These two steps are working parallel to prepare some informations for the next step.

a. Get Enforcement List (Code)

This section generates a list of “Yes/No” options to be utilized in the next step of the “Replacement Form”.

Once the Name and Description are defined for the step, the below code snippet creates the list and exports it as a variable to be consumed by the subsequent step.

// you can access form with                     => context.Data.formName;
// you can access any data in context with      => context.Data.variableName;
// you can access Workflow Id                   => context.Workflow.WorkflowId;
// you can access UserId of Starter             => context.Workflow.StartedByUserId;
// you can access Email of Starter              => context.Workflow.StartedByUserEmail;
// you can access UserName of Starter           => context.Workflow.StartedByUserName;
// you can access SourceId of Starter           => context.Workflow.StartedByUserSourceId;
// you can access UserId of Starter             => context.Workflow.StartedByUserSourceName;
// you can access Code of this workflow process => context.Workflow.Code;

var enforcementList = new List<object>();

enforcementList.Add(new {Id = $"Yes", Label = $"Yes"});
enforcementList.Add(new {Id = $"No", Label = $"No"});

return enforcementList;

Prepared “enforcementListGet“ is exported as a variable to be used in the form step.

b. Get Systems (Code)

This section generates a list of applications to be utilized in the next step of the “Replacement Form”.

Once the Name and Description are defined for the step, the below code snippet creates the list and exports it as a variable to be consumed by the subsequent step.

// you can access form with                     => context.Data.formName;
// you can access any data in context with      => context.Data.variableName;
// you can access Workflow Id                   => context.Workflow.WorkflowId;
// you can access UserId of Starter             => context.Workflow.StartedByUserId;
// you can access Email of Starter              => context.Workflow.StartedByUserEmail;
// you can access UserName of Starter           => context.Workflow.StartedByUserName;
// you can access SourceId of Starter           => context.Workflow.StartedByUserSourceId;
// you can access UserId of Starter             => context.Workflow.StartedByUserSourceName;
// you can access Code of this workflow process => context.Workflow.Code;

var coreSystems = new List<object>();

coreSystems.Add(new {Id = $"FlexCube", Label = $"Flex Cube"});
coreSystems.Add(new {Id = $"CMS", Label = $"CMS"});
coreSystems.Add(new {Id = $"RTPS", Label = $"RTPS"});
coreSystems.Add(new {Id = $"AMS", Label = $"AMS"});
coreSystems.Add(new {Id = $"ASC", Label = $"ASC"});
coreSystems.Add(new {Id = $"UFC", Label = $"UFC"});

return coreSystems;

2. Replacement Form (Form)

The Replacement Form step is used to collect information from the user who initiates the flow. You can find the details of the form fields and descriptions

Form Fields	Description
Grantee User Mail [Text] (granteeUserEmail)	It’s a textbox to get Grantee User Email address. It determines which user will get roles and permissions on the end application.
Grantor User Email [Text] (grantorUserEmail)	It’s a textbox to get Grantor User Email address. It determines which user accesses will be given to Grantee user such as roles and permissions on the end application.
Core Systems [Dropdown] (systems)	A dropdown that allows the user to select which system(s) the permissions will be granted for. The Core Systems dropdown values are generated in the previous step. To bind them, click the “Edit” button under the “Advanced” tab, as demonstrated.
Start Date [Date / Time] (startingDate)	A date picker that allows the user to specify the date on which their roles and permissions will be granted on the systems.
End Date [Date / Time] (endDate)	A date picker that allows the user to specify the date on which their roles and permissions will be revoked from the systems.
Is Old Will Remove? [Dropdown] (replacementEnforcement)	It specifies whether the user will keep their existing access rights on the systems. Is Old Accesses Will Remove? dropdown values are generated in the previous step. To bind them, click the “Edit” button under the “Advanced” tab, as demonstrated.