Workflow Actions
By definition, an action is a way, technique, or process of or for doing something.
In order to create a workflow process, preconfigured recurring actions can be helpful.
In this course we will cover how to use actions into the Flow module inside Deepser.
Lookup Record
If you want to get a record inside a Deepser model or entity in your workflow process, all you need is the action “Lookup Record” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Lookup Record” inside the FLOW section:
Then the following screen will open:
In our example, we want to get the record of the user that has created the ticket.
We choose the model “DeepAdmin – User” to get the entity of the user and then we set the expression or condition to filter the query.
In our case, we want to get the username equal to the Requester user of the ticket, from the trigger event.
Create Record
If you want to create a record in your workflow process, all you need is the action “Create Record” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Create Record” inside the FLOW section:
Then the following screen will open:
In our example, we choose the model “DeepService – Operation” because we want to create a new Operation (or ticket).
Inside the expression we set the “Type” field equal to the Service Type “Change” and we set the “Status” field equal to “New”.
In our case, the final outcome will be the creation of a new Change request with some precompiled fields.
All the variables were dragged and dropped from the right section inside the trigger variables.
For example, the “Title” and the “Requester User” of the new change were taken from the Operation that has triggered the process.
Update Record
If you want to update a record in your workflow process, all you need is the action “Update Record” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Update Record” inside the FLOW section:
Then the following screen will open:
For example, before the approval process ends, you want to update the status inside your ticket or Operation and set it as “Approved”.
In our example, we choose the model Operation in which we want to update the record (dragged and dropped from the right section inside the trigger variables).
In the Expression section we set the field “Status” equal to “Approved”.
Script Block
In this article we are going to analyse the usage of the “Script” block.
The “Script” block is located in the menu: Action, to access it you will also need to click on the search bar that will appear:
Script is used for more advanced calculations, that cannot be achieved through the default actions.
Script Input
On the input sections you can set all the inputs that are part of the flow and will be used on the calculations in the script. You can add a new input by clicking on the “+” button or delete an input by clicking on the “-” button.
Name: On this field you can set the name of the input value, this name will be later used inside the script.
Type: On this field you can select the type which has to be accurate to the input type, in this case we have an operation collection input.
Value: On this field you can set the value of the input. The value can be set manually, or it can be dragged and dropped from the right side of the flow variables.
Expression (Script)
In the expression section, you can write all the custom code needed for the calculations, by using the set inputs. In this example by using script block, we can calculate and retrieve tickets that have due date in a week. So, retrieved tickets could be used in a flow to be modified or to perform further calculation using default actions (such as Update Record, Lookup Record and so on).
// retrieve the subscription collection (from input)
$operationCollection = $this->getInput('operation_collection');
// retrieve the current date and the current day
$currentDate = new DateTime('now');
$currentDate->setTimezone(new DateTimeZone('UTC'));
$day = $currentDate->format('l');
// calculate the starting day of next week
$nextWeek = new DateTime('now');
$nextWeek->setTimezone(new DateTimeZone('UTC'));
$nextWeek->setTimestamp(strtotime("-1 day +1 week"));
$nextWeek->setTime(0,0);
$nextWeek = $nextWeek->format('Y-m-d H:i:s');
// calculate the ending day of next week
$endOfDay = new DateTime('now');
$endOfDay->setTimezone(new DateTimeZone('UTC'));
$endOfDay->setTimestamp(strtotime("+1 week"));
$endOfDay->setTime(0,0);
$endOfDay = $endOfDay->format('Y-m-d H:i:s');
//filter the operation collection based on the next week day interval
$operationCollection
->addFieldToFilter('due_date',['gteq' => $nextWeek])
->addFieldToFilter('due_date',['lt' => $endOfDay]);
// Set outputs with the result tickets
$this->setOutput('operations',$operationCollection);
$this->setOutput('operations_count',$operationCollection->count());
Script Output
All the outputs that are set on the expression area should be also set on the “Output” section. You can add a new output by clicking on the ”+” button or delete an output by using the “-” button.
Label: On this field you can set the label for this output variable, this label will also be visible on the right side of the flow.
Name: On this field you can set the name of the variable, this name should correspond to the name that is set for this variable on the expression script.
Type: On this field you must set the output type that is returned.
After saving the script block, the set outputs will appear on the right side of the flow and be ready to use. The outputs can be found under the “Script” label.
A complete example of script block-based flow can be found here.
Send Email
If you want to send an email inside your workflow process, all you need is the action “Send Email” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Send Email” inside the FLOW section:
Then the following screen will open:
Inside each field we set
| Name | Value | Note |
| Model | DeepServiceOperation | We set this model to take some variables that we need to send by email |
| From | Out | We set the Outgoing mailbox |
| To(Variables) | Assigned To (from DeepServiceOperation) | We want to send an email to the Assigned User of our Operation |
| Subject | Change Id #(entityId) Approved | We set the Subject of our mail including the ID of the ticket |
Inside the “Input” section we are going to set the Name of the variable, the Type of the Deepser model or entity and the Value of the Deepser model or entity that we want to use to create our body Html message.
Inside the “Body Html” section we are going to create our message that we want to show to the receiver.
Ask For Approval
If you want to create an Accept/Refuse request to the approval user/group inside your approval workflow and you want to send it into the Deepser portal or to send it by email, all you need is the action “Ask For Approval” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Ask For Approval” inside the FLOW section:
Then the following screen will open:
For example, we want to ask to a group of people to approve a service request, opened by some user.
In our example, we choose the model Operation or “ticket” in which we want to take some variables (dragged and dropped from the right section inside the trigger variables).
In the “Title” section we can write some text and show some variables from the ticket.
In our case, we take the Title and the Requester User related to the ticket from the trigger section.
In the “Approve Rule” section we can choose how the approval process can be approved and we choose to send the request to the Assigned Group assigned to the ticket (or Operation).
Inside the query builder we can find some options:
| Name | Description |
| anyone approves | any user or group chosen can approve the request |
| all users approve | all users chosen need to approve the request |
| all responded and anyone approves | |
| % of users approve | the chosen percentage of users need to approve the request |
| # of users approve | the chosen number of users need to approve the request |
In the “Reject Rule” section we can choose how the approval process can be refused and we choose to send the request to the Assigned Group assigned to the ticket (Operation).
Inside the query builder we can find some options:
| Name | Description |
| anyone rejects | any user or group chosen can reject the request |
| all users reject | all users chosen need to reject the request |
| all responded and anyone rejects | |
| % of users reject | the chosen percentage of users need to reject the request |
| # of users reject | the chosen number of users need to reject the request |
This configuration allows you to send the request through the Deepser portal.
If you want to send it by email, you need to enable the flag “Enable Email Approval”.
Log Action
If you want to display a message inside your workflow, all you need is the action “Log” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Log” inside the FLOW section:
Then the following screen will open:
For example, inside our workflow we want to display the message:
“The status of the ticket with #ID was not modified”
In our example, we choose the Model Operation to get the entity ID of the ticket (variable dragged and dropped from the right section) and write some text to show our message.
This message will be visible after the execution of the workflow inside the “Execution” tab across the log section. The log file can be also downloaded.
Note: Logs will be visibile only if the flag “Enable Log” inside the Flow Properties is enabled (see article)
Stage Action
If you have divided your workflow into several steps with the module “Stage Set” and you want to add into your workflow the steps that you have created, all you need is the action “Stage” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Stage” inside the FLOW section:
Then the following screen will open:
The final outcome will be:
Stage Error
If you have divided your workflow into several steps with the module “Stage Set” and you want to add into your workflow another step where you want to display an error stage, all you need is the action “Stage Error” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Stage Error” inside the FLOW section:
Then the following screen will open:
SFTP – Actions
The SFTP actions within Deepser’s FLOW module are an advanced feature that allows interaction with files on remote servers via the SFTP (Secure File Transfer Protocol). They are designed to automate file transfer operations within customized workflows, ensuring security, flexibility, and integration with external systems.
The configurable features include:
- Uploading/Updating files on a remote server
- Downloading files from the remote SFTP server
- Deleting files on the remote server
To insert one of these actions, you will need to add a new node and search for the corresponding action:
SFTP Upload
Once the “SFTP Upload” action is added to the flow, it will appear as follows:
Below is the field breakdown:
Name | Notes |
Host | Through this field, you will need to enter the host of the remote SFTP server. |
Port | The port used for the connection. |
Password | This is the password required to access the SFTP server, and it can only be loaded via Deepser’s Password module. Therefore, the password must first be saved in the dedicated module, and then retrieved using the “Lookup Record” action to be used within the node. |
Timeout (seconds) | The number of seconds within which the request must be executed. |
Destination File Path | The path on the remote server where the file must be uploaded. In this field, you need to enter the full name (path + file name). Example: /home/user/documents/report.csv |
Attachment | The file to be uploaded to the SFTP server must already be present within Deepser. It must therefore be loaded into the flow using the “Lookup Record” action, and then referenced in this field. |
Replace if exist | During the upload phase, this option forces the file to be overwritten if a file with the same name already exists on the remote server. |
SFTP Download
Once the SFTP Download action is added to the flow, it will appear as follows:
Below is the field breakdown:
Name | Notes |
Host | Through this field, you will need to enter the host of the remote SFTP server. |
Port | The port used for the connection. |
Password | This is the password required to access the SFTP server, and it can only be loaded via Deepser’s Password module. Therefore, the password must first be saved in the dedicated module, and then retrieved using the “Lookup Record” action to be used within the node. |
Timeout (seconds) | The number of seconds within which the request must be executed. |
Source File Path | The full path on the remote server corresponding to the file to be downloaded and saved in Deepser. Example: /home/user/documents/report.csv |
Attachment Expression | Through this query builder, it will be possible to configure the fields of the Attachment object that will be created. At this stage, you must also include any references to the main record to which the downloaded file should be linked (Model Alias and Model in the example). |
SFTP Remove
Once the SFTP Remove action is added to the flow, it will appear as follows:
Di seguito il dettaglio dei campi:
Nome | Note |
Host | Through this field, you will need to enter the host of the remote SFTP server. |
Port | The port used for the connection. |
Password | This is the password required to access the SFTP server, and it can only be loaded via Deepser’s Password module. Therefore, the password must first be saved in the dedicated module, and then retrieved using the “Lookup Record” action to be used within the node. |
Timeout (seconds) | The number of seconds within which the request must be executed. |
Source File Path | The full path on the remote server corresponding to the file to be deleted. Example: /home/user/documents/report.csv |
SSH
The SSH Action is a feature of the FLOW module that allows remote command execution on Linux/Unix servers via the SSH (Secure Shell) protocol. It is designed to automate system administration tasks, maintenance operations, or integrations with external environments, directly within a Deepser workflow.
To insert the SSH action, you need to add a new node and search for the corresponding action:
Once the “SSH” action is added to the flow, it will appear as follows:
Below is the field breakdown:
Name | Notes |
Host | In this field, you must enter the host of the remote SSH server. |
Password | This is the password required to access the server via SSH, and it can only be loaded through Deepser’s Password module. Therefore, the password must first be saved in the dedicated module, and then retrieved using the “Lookup Record” action to be used within the node. |
Port | The port used for the connection. |
Timeout (seconds) | The number of seconds within which the request must be executed. |
Command | Multivalue field. Through this field, you can specify all the commands that must be sent to the server via that specific node. In the example, a custom backup script is executed |
API nodes and WEBHOOK
API Node Configuration
In this case, Deepser is called by an external system. This means that a third-party application or service can send a request to Deepser, which will respond by returning data based on how the relevant flow has been configured.
This mode allows you to create and manage custom API calls, which can be invoked by external applications to obtain information, initiate processes, or perform specific actions on Deepser.
First, you will need to create the flow for the API call by going to Flow > Designer and clicking the “New +” button, selecting the API trigger, and clicking the “Save” button.
Once saved, the highlighted link will appear, allowing you to call the flow.
NOTE: The highlighted link represents the endpoint provided by Deepser.
The following fields are available in the Flow trigger:
Field | Description | Note |
Type | Trigger type |
|
Input | Fields passed by the API call | Visible if type is API |
Output | Fields returned by the API call | Visible if type is API |
Enabled Groups | Groups authorized to execute the flow from the call
| Visible if type is API
|
Enabled Users | Users authorized to execute the flow from the call
| Visible if type is API |
Enable End Users | Enabling end users to execute the flow
| Visible if type is API
|
After configuring the flow trigger, you can proceed with the code to be executed.
To assign the value to the variable “result”, which is returned by the flow, you will need to insert an “Assign values to API Outputs” node.
The node will allow you to assign a value to the output variable “result.” If multiple fields have been entered in the trigger, the node form will display all the fields entered.
Webhook Node Configuration
In this case, the operation is reversed: Deepser calls the APIs of an external system.
By configuring a webhook, you can ensure that when a specific event or condition occurs within Deepser (e.g., the creation of a ticket, the modification of a status, or the assignment of a task), the system automatically sends a request to another external software or service.
This logic therefore allows you to automate the exchange of information and integration with third-party applications, without the need for the other system to query Deepser directly.
The Webhook node can be used with any trigger set.
The node can be found by clicking Action (1) > Core (2) > Webhook (3)
The form that will open will be as follows:
Field | Description | Note |
Method | Calling method
| For webhooks, it is usually “Post.” |
Url | Endpoint to which the call is sent |
|
Authentication | Type of authentication required to authorize the call |
|
Headers | Key-value pairs included in the HTTP request, useful for passing additional information | e.g. Content-Type: application/json, security token, event identifiers |
Query Params | Parameters passed in the URL after the “?” symbol in “key=value” format | used to filter, sort, or provide additional data to the request
|
Body | HTTP request content |
|
Advanced Config | Allows you to view fields related to advanced configurations. |
|
Disable SSL Verification | allows you to disable SSL certificate checking during HTTP calls
| Only visible if “Advanced Config” is set to “Yes.”
Disabling this option is not recommended in production environments because it reduces security and may expose you to attack risks. |
The following data will be retrieved from this node:
Field | Description |
Code | HTTP status code returned by the server, used to determine whether the call was successful. |
Headers | Response HTTP header |
Body Raw | The content of the response in text/raw format |
Body Json | The same response, but already interpreted as JSON |
Error | Indicates whether an error occurred in the call. It will return “true” or “false.” |
Error Message | The error message |
In practice:
- If the call is successful, the following will be returned: “Code” = “200”, ‘headers’ and “body”.
- If the call fails, you will find “Error” = ‘true’ and an “Error Message” explaining what went wrong.
Flow duplication
The Deepser application provides all users with the capability to duplicate an existing flow. This functionality is particularly useful when there is a need to replicate a pre-configured process or workflow, saving time and ensuring consistency across different operations. The duplication process can be carried out manually through the Flow module within the application interface. By following a series of straightforward steps, users can create a new flow based on an existing one, preserving its structure, configurations, and logic. In the following sections, each step required to duplicate a flow will be explained in detail, guiding users through the entire process to ensure a smooth and accurate replication.
- Begin by accessing the existing flow that you wish to duplicate.
- Once inside the flow, locate the Edit button in the top-right corner of the screen (next to the Status button).
3. Click the Edit button to open a new window. At the bottom of this window, you will find the Duplicate button.
4. Click the Duplicate button to open duplication options:
a.New Name
b.Duplicate as Subflow
c.Duplicate also Subflows
d.Version
5. Flow Duplication:
a)To duplicate the flow as a standard flow, leave the Duplicate as Subflow option set to its default value of No, then click the blue DUPLICATE button to proceed.
b) To duplicate the flow as a Subflow, change the Duplicate as Subflow option to Yes, and then click the blue DUPLICATE button to complete the process.
Log Action
If you want to display a message inside your workflow, all you need is the action “Log Action” inside your workflow. After opening your workflow process inside the “Flow” module, to add the action “Log Action” inside the FLOW section:
Then the following screen will open:
For example, inside our workflow we want to display the message:
“If you are reading this message it means that the new ticket is Created.”
This message will be visible after the execution of the workflow inside the “Execution” tab across the log section. The log file can be also downloaded.
Note: Logs will be visibile only if the flag “Enable Log” inside the Flow Properties is enabled (see article)
Another method for creating a log involves using a custom file. Under the log node, there is a File command where you need to enter a value—this value will serve as the name of the log that appears under System > Tools > Log > System Log. To illustrate this method, we’ve provided an example using the file name “test_to_create_log”.
After creating the ticket, navigate to System > Tools > Log > System Log, where the new log will appear with the same name as the file shown in the example.
When accessing the log, the message entered in the Log section from the first image will be displayed.
Create Variable
A new node has recently been added to the flow, designed specifically for variable assignment. This logic node, named “Create Variable,” enables users to create a new variable and assign a value to it. The value can either be a fixed, predefined input or the result of a previous operation or process within the flow. This functionality provides greater flexibility and control when managing data throughout the workflow.
Before creating this node, you must complete the following four mandatory fields:
Field | Note |
Label | Specifies the display name of the variable, which will appear in the right section under trigger variables. |
Name | Defines the internal name of the variable. |
Type | Determines the variable’s data type based on your use case. There are 9 available types, including integer, string, boolean, datetime, and others. |
Value | Assigns a value to the new variable, selected from the options in the right section under the trigger. |
Delete Record
If you want to delete a record in your workflow process, all you need is the action “Delete Record” inside your workflow.
After opening your workflow process inside the “Flow” module, to add the action “Delete Record” inside the FLOW section:
In our example, we choose the model Operation in which we want to delete the record (dragged and dropped from the right section inside the trigger variables).
