This document is an Administration Guide for creating and editing Process Automations in the Actionabl system. It is intended for Actionabl Technical Users.
Actionabl.ai is a platform that automates your business processes and alerts users whenever human intervention is needed.
This guide covers the creation and editing of process automations within the system, including connectors, tasks, rules, and forms.
If you are a new technical administrator of Actionabl, you should first review Getting Started with Actionabl to familiarize yourself with the key concepts and terms used throughout this document.
Unless otherwise noted, all Actionabl admin menus mentioned in this document are found under the Admin dashboard, accessed from your user profile.
In Actionabl, the Process View defines an automation and how data flows through the system. It has a number of components:
In addition to the elements shown here, a Process Automation also may use:
Please review the Task Management Guide to understand how processes, tasks, and stages work together to form a process automation. The concepts from that guide are critical to your understanding to enable you to create and manage process automations effectively.
When designing a process automation, it’s tempting to just start building the flow in the system. However, this is the least efficient approach and can cause frustration. We recommend the following process.
Steps 1 through 7 are done outside of Actionabl using your preferred flowcharting method and tools. Step 8 is done in Actionabl.
Build the process flow
Start by sketching the process flow. This flow should include all inputs and outputs, decision points, tasks, and status transitions for items flowing through the process.
Identify your data sources
Identify all of the data sources that this process uses in each of its tasks. This includes all APIs, communications, human inputs, databases, and forms.
Define the data
For each task in the process, clearly define the data it will use, including inputs, outputs, and any translations or calculations.
Each data point should have an identified source and a storage point.
Define Tasks, Rules, and Connectors
In your process flow, fill in the details of each task and all of the connectors and rules that govern it.
For example, if you have a task that validates an invoice, list the validations to be performed (e.g., date, vendor, quantities matching a PO, looking for a VIP flag, dollar thresholds, etc.).
If your task uses an action like OCR or a bot, list the specific actions to be performed and the inputs and outputs of those actions.
As you build your tasks, connectors, and rules, group them into the appropriate Stages.
Define Decision Points
For each potential branch in the flow, clearly define what the decision is evaluating - the field(s), groupings, logic, and conditions.
Define How Items Flow Between Tasks
Each task must have an input and an output flow. The flow is what moves the item between this task and its next one and may involve logical rules to determine which task comes next. Define each flow and each possible branch an item can follow.
When a task such as a decision model has multiple outbound flows, one of those flows must be defined as the default. The other flow(s) are then defined by their rule (such as “is_approved=yes”) to direct the item into them.
For example: if a task is a decision model determining whether an item must be manually reviewed, it will have two outbound flows: one for “yes” and one for “no.” The “yes” flow directs the item into a manual review step, while the “no” flow goes to an automated payment task.
Define The Resolution Task(s)
Ensure that every pathway has a well-defined resolution task as its endpoint.
Build the Process Components in Actionabl
Now that you have all of the process components defined, you can start building them in the system. If you start at the most granular level and build up from there, the elements you need for more complex items like tasks will already be in place when you’re ready to use them.
In Actionabl, we recommend that you build items in this order:
A Data Field is a container for a defined, discrete, element of data stored in JSON format within Actionabl. A field has the following characteristics:
In this example, the field is a multi-select field allowing labels to be set on Bank Invoices:
This example is an attachment field that can hold multiple file uploads:
If an existing field is configured similarly to the new field, you can duplicate the existing field and use that as the basis for the new one. Alternatively, click the green plus icon on the top right of the field list to create a new field from scratch.
If you are on any page other than 1 in the field list when you click the green plus sign, the new field will not appear to be created. However, if you go back to page 1, you will find the dialog for it open at the top of that page.
Click Save when done.
You can only Edit fields that you or another user have created; fields created by Actionabl cannot be changed. However, you can Duplicate any field in the system and make changes to its structure and characteristics.
In the Components section of the menu, click Fields to open the list of fields.
You can easily filter the list of fields by:
You can also search for a field using Table Search by entering any of the information displayed in the table (name, type, control type, updated by user, etc.).
Click the Expand icon to open the field you want to edit or duplicate. If you can edit the field, it will look like this:
Otherwise, it will look like this:
Click Edit or Duplicate to continue.
Duplicating a field only copies its definition, not the data contained in it.
In the window, you can now select or change all of the elements of the field.
If editing an existing field that is in use, be aware that changing its type, data format, validation, or control type may create errors in existing processes or forms that use the field.
Exercise EXTREME CAUTION, as editing a field can result in a permanent loss of data if existing field values are converted. Once a process is in production, field types, data formats, validations, or control types should not be changed.
Data sources are static tables of data that can be queried against as a reference, but that cannot be updated by the automated processes.
Let’s use an example where we track a list of attendees at a yearly event. Each year’s attendance records are kept in an XLS or CSV file.
Data sources have 3 components:
Data Source Definition. This is the table definition for the data, specifying the following for each column: field name, display name, data type, and whether the field is hidden. A data source definition can be mapped to multiple data sources as long as their structures are identical. For example, the same data source definition can be used for every year of the event’s attendee records, as long as those records have the same data structure.
Data Source Mapping. This entry maps the data source definition to a specific instance of the data and sets the field on which to match the definition to the data. This is where the data source definition for the event would have multiple entries, one for each of the event years.
Data Source File. This is the file that contains the actual data (the attendee information for year 2, for example). This can also be a key:value entry you’ve typed or the results of a Bot’s actions.
Field Name should exactly match the column header in the data source file.
Field Title can be anything you’d like. This is how the data will be labeled in the interface, reports, etc., within Actionabl.
Select a Data Type that represents how the data should be interpreted from the source file.
Click Hidden if the field should not be displayed in Actionabl. Its data is still available for use in rules and calculations.
Your data source definition maps to:
In the Data Sources tab, click the green plus sign to create a new data source from scratch.
The next step will vary depending on the Source you select.
This source assumes you have a relatively small set of data and that you’re going to type it in here. Clicking this loads a table showing the data definition you specified.
Click the green plus sign at the far right of the table headers to start adding data.
As you add data here, note that the fields specified as Date-Time have a date/time picker and restrict data entry to match. Likewise, the Boolean field, Attended, has a simple checkbox. The “Sign Up Date” field is hidden from inputs.
You can keep adding rows by clicking the green plus sign and delete any that you don’t need by clicking the red X.
Click Save when you’re done and the dataset is ready for use.
The File source type assumes that you’ve uploaded a file to the filesystem, which makes it available for selection.
To do this, you can place the file in a folder or leave it at the root level for uploaded files on your system. If you aren’t sure how to upload this file, consult with your system administrator or DevOps/IT department.
When you select File as the source type, your input screen will look something like this:
Click the [ ] icon in the File field to see the available files in the system.
Note that some of the list entries (like Attendee Records) are described as Folders. Clicking one of these opens the folder and shows the files in it. To return to the previous list level, click the double dots at the top left of the list.
The result should look something like this. Note that the File field shows both the folder and the filename:
The File Upload source type differs from the File type in that it prompts the user for an uploaded file when the data source is called. This is especially handy if recent or refreshed data is needed whenever the data source is used.
The Bot source connects the data source to a bot script, which runs using the specified parameters whenever the data source is called. This is especially useful when a complex process or data assessment is required to generate a result set for use. For example, you might create a script that calls a REST API to fetch data, which is then manipulated to be used as a data source.
Click the browse icon [ ] in the Bot Script field to select the script to run.
See the Automation Management Guide for information on how to set up Bot scripts, if needed.
Note that some of the entries on the list are described as Folders. Clicking one of these opens the folder and shows the files in it. To return to the previous list level, click the double dots at the top left of the list.
After selecting the script, click the green Plus sign to the far right of Script Parameters to set up the script’s inputs. These parameters are passed to the bot each time it is started by this specific Data Source being called.
Enter the parameters specific to that Bot script. You can also enter parameter groups, if needed.
Files such as those used in data sources must be uploaded directly to the file system in the Project/Folders/Resources/Published/Files folder. For ease of maintenance, we strongly recommend creating subfolders here and using a consistent naming system to organize your files.
File uploads are made by a technical user or administrator who has been granted access, usually using an FTP client.
Once a data source is uploaded, it cannot be directly edited. To update the contents, upload a replacement file with the exact same filename.
Each task needs an action, so before creating it, we need to ensure that the appropriate actions are defined in the system.
Go to Components -> Task Actions to see and edit the actions already defined or to add a new action.
Actions can have one of seven types:
Records are definitions of connections or templates that can be used in a process, task management, or a connector. They include things like:
Records are managed under Components -> Records.
PM62
To see the content of an existing record, click the Expand icon on its far right. The fields displayed will vary based on the type of record you’re viewing.
Example of an email template record:
Example Service Account Profile record:
Example FTP Account record:
Start by clicking the green plus icon at the top right of the record list. The New Entry dialog appears:
Select the Type of record to be created.
This can use any IMAP/SMTP email account.
The middle section of this dialog defines the intended recipient(s), CC, and BCC addresses for the email to be sent. These entries can be left blank, in which case the task that calls this template will fill in this data.
The bottom section defines the content of the email, including subject line, sender/reply-to, type of email, and a custom body.
When you select a Body Type, you will see the fields available to you change.
Default Email Body
Mail Gen Email Body
Custom Email Body
Detailed instructions on building and managing Email Templates are provided in the Communications Administration Guide (COMING SOON).
When you use the Mail Gen email template type, you can use predefined sections to build your email. Email sections are reusable snippets that can be brought into multiple email templates to provide consistent messaging, formatting, or functionality.
Examples:
- Greetings / Salutations
- Tables of data
- Contact and hours of operation
- Paragraphs containing a refund policy
- Links to learning and documentation resources for your product
When a section is used in an email template, it appears like this.
Clicking the Expand button allows you to see the content of the section.
If you are in Edit mode on the email template, you can also edit the section’s content. For text items, clicking “Edit Paragraph” opens a rich-text editor in a separate popup. Other items can be directly edited.
Click Save in the popups and when finished editing the sections to ensure your work is saved.
Detailed instructions on building and managing Email Sections are provided in the Communications Administration Guide (COMING SOON).
Message templates are used for SMS messages and threads. The structure of the message templates is simple because there is no formatting involved, but they can include variables, which are enclosed in double curly braces .
When completed, it looks something like this:
An FTP Site record provides a full definition for connecting to and using an FTP or SFTP site. It looks like this:
The result will look something like this:
Parameter records are lists of parameters (Name, Type, and Value) that can be used by Connectors and Tasks to complete actions. They are helpful when the same parameters are frequently used to define a task, such as a company name, address, filename, or path.
Service accounts define an external account that the system can use to connect to and perform actions in an external service.
Available Account Types:
- Docusign
- Google Workspace
- Microsoft
- Dropbox
- Box
Setting up a service account requires the full credentials to the remote account and, when appropriate, also allows you to create or revoke an access token in the account.
Multiple service accounts can connect to the same service as long as they use different account credentials. For security, each service account should use a dedicated login and have the least privileges needed to perform its role.
The fields available when setting up a service account will vary with your selection of service type.
For a Google Service Account you will need a Client ID and a Client Secret as well as your Google Tenant ID. Details for setup in Google are available in their Developer Documentation.
The Client ID and Secret are only shown once in Google and are NOT visible after you enter them in Actionabl, so save them in a safe place.
If you lose these credentials, you must revoke the existing keys and generate new ones, then enter the new ones into the service account setup in Actionabl.
In Actionabl, select a Service Type of Google to set up the service account.
When complete, the record should look something like this:
Setting up a Microsoft Service Account
For a MIcrosoft Service Account you will need a Client ID and a Client Secret. Details for setup within Microsoft are available in their Partner Center documentation.
The Client ID and Secret are only shown once in Microsoft and are NOT visible after you enter them in Actionabl, so save them in a safe place. You should also record the start and end dates for the secret as this is also not available once you close this dialog.
If you lose these credentials, you must revoke the existing keys and generate new ones, then enter the new ones into the service account setup in Actionabl.
The new client secret may take up to 15 minutes to activate. During that time, you can save it in Actionabl, but testing this record may not be successful until it has activated in Microsoft.
In Actionabl, select a Service Type of Microsoft to set up the service account.
Once set up in Actionabl, your Microsoft Service Account record should look something like this:
Setting up a Box Service Account
A service account is automatically created in Box.com when you create a custom app or partner integration in the developer console using the JWT authentication method. Once this is created, you will need to create Client ID and Client Secret and to retrieve your Box Tenant ID (in the Microsoft Entra admin center under Properties).
In Actionabl, select a Service Type of Box to set up the service account.
To get the Client ID for your application, log in to your Box developer console and click the Edit Application link for the application you’re working with. In the OAuth 2.0 Parameters section of the configuration page, find the item labelled client_id. The text of that item is your application’s Client ID.
Setting up a Dropbox Service Account
Your Dropbox Service Account starts with setting up a new app in Dropbox on the App Console in your account. Details about how this works are found in Dropbox’s documentation.
After setting up the app, you will see an App Key and App Secret, which you’ll use for Actionabl setup. You will also need to retrieve your Dropbox Tenant ID or Team ID from the admin console or Developer Portal.
In Actionabl:
Setting up a DocuSign Service Account
Set up your DocuSign integration by creating a free developer account in the DocuSign Developer Center and generating a Client ID and Client Secret. You will also need to retrieve your DocuSign API Account ID, which serves as your Tenant ID.
You will likely also need to set up a DocuSign Connect connection to enable the real-time integration.
In Actionabl:
A service profile record uses the service account previously defined to connect to the external service so an action can be performed. The Profile is what a Connector uses to log in to the remote service and complete a specific task.
For the Google Service Account that was created, for example, we may have 6 Profile Records that have unique privileges and accesses.
Each profile is granted specific accesses and has a unique token for its connection:
When you create a new Service Profile, you first need to select which Service Account it uses. This will determine the fields and configurations available to it.
Next, you will need to select an Auth Grant Type.
After you create and save the profile account, you will be able to create or revoke its tokens.
Click Create Token to create a new one. You will not see the token or any confirmation that it has been created. However, the token will be used automatically in the API calls made to Google to represent this profile as an authenticated user.
If you have problems with authentication or make changes on the remote end of the API connection, you may need to revoke the token and then create a new one.
To turn off authentication between the two systems, click Revoke Token to remove the token. This will prevent all future API calls from authenticating.
It’s strongly recommended that you define the profile’s ID and Name based on the authorization scope(s) being granted to the profile. If you have multiple Google accounts, include the account name in the ID and profile name as well.
There are two “tiers” of authorization scopes to define in a Google Service Profile: Drive access and App access.
Drive Access options:
App Access options override drive-level permissions on an app-specific basis:
For clarity, here are some common scenarios:
Profile that can read and write Spreadsheet files only
Profile for full Gmail Send/Receive access
The Microsoft Service Profile has 7 authentication scopes available:
Example showing full access to a Microsoft Service Account
For Box, the only service profile option is whether to grant full access.
For DocuSIgn, the service profile designates whether this account can “impersonate” a signature. This would provide the authority to sign a document on behalf of a person or organization.
ESign Template Records use the DosuSign Service Profile to route a signature “packet” of documents (as file attachments to emails) to signers for their approvals.
For example, let’s assume you are sending a set of 3 documents, each of which need to be signed:
- Disclosure of terms
- Credit check authorization
- Application for credit issuance
These documents will be sent in a single packet called “Credit Application” to the applicant and co-applicant, plus the business’ credit manager.
While tasks represent a set of internal actions and rules that achieve a specific goal, connectors are where the actions actually take place.
There are 6 categories of connectors in Actionabl, each of which is covered in detail below:
Connectors are created by going to Components -> Connectors and clicking the green plus icon on the top right.
To manage or duplicate an existing connector, click the expand icon next to it in the list.
WARNING!
If a connector is currently in use, you must pause the automation(s) in which it’s used prior to making any edits to it.
Best Practice is to duplicate the connector, make the changes and thoroughly test them, then replace the old one with the new one in the process automations. You can then restart the automations. You should then delete the old connector to avoid confusion.
DO NOT delete a connector until you are certain that no automations or processes use it.
When you expand an existing connector, you see its details and can also take the following actions.
You can take the following actions on connectors:
Click the green plus sign at the top right of the connector list to open a new connector dialog at the top of the first page of connectors.
If you are on any page other than 1 in the field list when you click the green plus sign, the new field will not appear to be created. However, if you go back to page 1, you will find the dialog for it open at the top of that page.
The Start Event connector is the action that starts a process.
Typical examples are:
- Receiving an email
- Monitoring a folder for a new or changed file
- A cron job that periodically runs the process
It can have one of the following Types:
A cron start event indicates that a script, set up under Control Center -> Cron Job Scheduler, will run on a defined schedule and execute a script. The output of that script starts the process.
For example:
- A cron job runs an external API query every night at 2 AM to pull in new account signups from a website.
- When that job runs and finds new accounts, that starts the process.
The cron job is scheduled like this.
The connector is set up like this:
The HTTP start event occurs when an outside system calls Actionabl from a preconfigured URL.
For example, you may have a service that handles shipping of orders; when the order ships, their application calls Actionabl and provides a tracking number, shipping invoice, and date of shipment.
In this example, we want to save the attachment of the shipping invoice as an Inbound OCR with everyone in the workgroup having access to it.
In subsequent tasks in the flow, we ould then read the invoice and send it for processing, extract the tracking information and email it to the customer, and update the order’s status to shipped.
The configuration of the URL and API access tokens for the connection are done using the Automation Scheduler. Details for this setup are in the Automation Management guide
A start event that monitors an email account and reads incoming messages that match specified criteria has a Read Email type. The specific sub-types of this event for Gmail and MSMail differ only in their background processing to correctly connect and authenticate to the type of email service.
For example:
- A process schedule in the Bank Invoice Process uses the Bank Invoice Read Email connector.
- This connector runs every 30 seconds to monitor for incoming emails that match its criteria.
- When one is found, it reads the specified fields and runs the Inbound OCR process on any attachments to create an item in the Actionabl system (such as INV-27), then moves that item into the first task in the Bank Invoice Process.
The Process Schedule is set up like this:
The Start Event looks like this:
The Read Folder start event monitors the specified folder. When it finds new, changed, or deleted files that match the criteria in the filter, it triggers the start of the process.
For example:
- The Bank Invoice Process monitors a folder where some vendors upload their invoices instead of sending them via email.
- When it finds a new invoice in that folder, it starts the process.
This event can monitor any folder on the server; make sure to specify a full path to the folder.
This connector looks like this:
This event type monitors a specific file and starts a process when that file changes. For example, it could monitor a spreadsheet and start the process when rows are added or updated.
For example, let’s look at the Consortium Attendees file we defined as a data source.
Set up the start event and then click the browse icon [ ] next to Data Source.
To verify that you’re looking at the right data source:
Click the Expand icon next to any of the data sources to see its definition and click Display Data to access its data.
On the list of data sources, click the data source name to display its schema.
Next to each field you want to map into this process item, click the browse icon [] under the Process Field and select the field that it should map to.
Click the field that this data should map to from the list of all fields in this process.
Continue mapping fields in this way until you have mapped all data that you want to bring in for this process item. This step ignores unmapped fields. For example, the “Attended Sessions” data in the screenshot below will be ignored.
Once you’ve mapped all of the desired fields, click Save.
You can now test the mapping to ensure it is acting as you expect.
The FTP start event monitors the server on the FTP port. When defining this event, you can define the FTP commands to execute (both inbound and outbound) and the action to be taken when the process starts.
A Custom Start event executes the code script specified using the event’s parameters. The script’s output is used as input to the first task in the process.
Custom Start Events are run manually when a user clicks them in the task list.
The database query start event connects to a database using the connection parameters in the connector. Once connected, it runs an optional Data Processing Script and executes an SQL query. The query’s output triggers the start of the process and serves as the input to the first task in the process.
This start event is triggered by a cron that runs the database query event on a scheduled basis.
OCR connectors pass items from the previous task into an OCR task. They may perform pre-processing on the item, such as ensuring that the file matches a type that can be read through OCR.
There are 4 types of OCR connectors:
The Actionabl OCR connector uses our built-in Tesseract instance. It asks you to specify whether to extract plain text or fields from the document. If you select this connector type, you can also specify which cluster to run the process in. Clusters are used primarily for load-balancing processes that use intensive CPU resources.
The Hyper Science connector launches an instance of your own Hyperscience account that you define by inputting:
Available by request. Please contact Actionabl for information.
Available by request. Please contact Actionabl for information.
RPA connectors enable the software “robot” to mimic a human’s interaction with a site or piece of software to complete repetitive, rule-based tasks. This can include things like making selections from dropdown menus, entering data, interacting with popup menus, or picking a date in a date-picker field.
There are four “engines,” referred to as Types, that RPAs use to interact with external resources:
These engines can interact with a number of external resources, including:
If you are using something other than the built-in engine, you will configure the RPA in that application. This may also provide you with the ability to interact with resources other than the types listed above.
We recommend using the Actionabl RPA connector when you are creating an automation from scratch and you understand how to connect the RPA into your business process flow. If your existing process flow uses UI Path or Automation Anywhere in any part of the flow, use these connectors instead to quickly roll out your solution.
The Actionabl RPA connector defines the connector and its actions, as well as the authentication to the external resource it interacts with.
For example,
- You have an RPA script that checks a calendar for available time slots to schedule.
- When Connector A runs, it uses the script to check the calendar for availability on weekdays, so its RPA parameters specify that.
- When Connector B runs, it checks the calendar for weekend availability only, as specified in the RPA parameters.
This RPA connector uses the UI Path service to complete the RPA operations. This connector’s input specifies how to connect to UI Path and which definitions and priorities to use to execute it. The actual RPA script definition is set up within UI Path and the parameters for it are set there, as well.
This RPA connector completes RPA operations using the Automation Anywhere service. Its input specifies how to connect to Automation Anywhere. The actual RPA script definition and parameters are set up within Automation Anywhere, as well.
COMING SOON. Integration available by request.
There are many AI connector types available. Each plays a very specific role in moving an item between two tasks. When you select the Type, the dialog changes the fields available for configuration.
Type | Definition |
---|---|
AI Space | Allows the user to run a model and execute actions against it. |
AI Agent Heal Extraction Error | After extracting data from a document using OCR, this agent corrects any errors in the data. |
AI Agent Heal Data Error | After validating data, this agent corrects any errors found in it. |
AI Agent Web RPA | Performs a Web RPA action, such as logging into a system and entering invoice data into a web form. |
AI Agent Win RPA | Performs automation on Windows applications. |
AI Agent SAPRPA | Performs automations on SAP. |
AI Agent Form OCR | Extracts data from a form using OCR. |
AI Agent Card OCR | Extracts data from an ID card, such as a driver’s license or PAN card. |
AI Agent Document OCR | Extracts data from a document. |
AI Agent Doc Classification | Identifies the type of document being read, such as a driver’s license or PAN card. |
AI Agent Page Classification | Classifies each page in a document and returns classifierwise page numbers. |
AI Agent Summarization | Summarizes the document being read. |
AI Agent Topic Summarization | Summarizes a specific topic within the document being read. |
AI Agent Sentiment Analysis | Given a text block, identifies the sentiment (e.g., humorous, informative, sad, hateful, etc.) |
AI Agent Entity Extraction | Extracts structures data from a mixed (structured/unstructured) document. |
AI Agent Question Answering | Asking questions based on the document provided for which user will receive answers. |
AI Agent JH Validations | Validations information such as account or loan data from the SymXchange/JackHenry account. |
AI Agent Custom | Custom-created AI Agent, which runs locally on the AI model. Used when you need something that differs from the existing agents. |
AI Agent External | Custom-created AI Agent, which runs on the AI model on the cloud. Used when you need something that differs from the existing agents. |
The App connectors represent core task functionality. These are some of the most powerful types of connectors and are widely used throughout a typical Actionabl process flow. They include:
Email app connectors send emails from the system and allow for customization of the template and contents based on where the connector is used.
Email Account / Service Profile is the sending account to use for the email. Leaving this blank uses the default email or service account as defined at the process level.
Email Template selects the template that defines the email’s contents and recipients. These templates usually include variables, representing the data passed into the process step.
If a variable is included in the template but is not available in this step of the process, it will be left blank in the resulting email.
The Email Type is Reply, Reply All, New, or Forward. Your choice determines which fields within the email template are needed and who is included in the sending list.
Save Email should be checked if you want to keep a copy of the email in the email history.
Communication Mode determines whether the recipient is able to respond to the email directly.
Prepared Email Body Field is used if the sender is manually drafting the body of the email. This field contains the draft of the email content that will be sent by the Send Mail connector.
Exclude Emails To is a list of email senders who should be excluded from any replies or reply-alls.
This example is an invoice receipt acknowledgment email connector that is sent immediately upon receiving a vendor’s emailed invoice.
The connector is set up like this:
The email template, Bank Invoice Receipt Email, looks like this:
You can expand any of the Email Body sections to see the actual text and variables. Items in double curly braces represent variables.
The send message app connectors send SMS text messages from the system using a template you create within the connector or a predefined message template. The template can reference variables for data fields that are passed into the task where the connector is called. If the template references a variable that is empty, the field will simply be left blank in the message.
The connector is set up like this:
To select or edit the message template, start by clicking Edit in the actions menu, then click the browse icon [] in the Message Template field. If there is a selected template, you’ll see its contents like this:
You can edit the message content by clicking Edit again in this popup. Make your changes and click Save.
If you click Cancel here instead, you’ll see a list of all message templates that have been defined in the system and can select one to use here.
It is strongly recommended that you Test any message configuration after saving it, especially if variables are being used.
In Actionabl, push notifications are found in the Communications dashboard under Notifications. The Push Notification app connector creates a push notification for the item. They are commonly used to alert that a task has been created or completed.
The connector is very simple.
The content of the notification is an alert that the task action has been taken.
The Read Folder app connector monitors a specified folder on the system and takes action when it finds files that match the configuration and/or filter specified.
When a new, matching file is found, the connector can save it as an attachment to the item, configure access to it, and assign it a category.
The connector is set up like this:
Selection Criteria:
Attachment Configuration:
Once configured, the connector will look something like this:
This event type reads the specified file and uses the file’s content to add to the item. Once the file has been read, a corresponding file with the suffix .done is created, which prevents the file from being read again.
For example, let’s look at the Consortium Attendees file we previously defined as a data source. Click the browse icon [ ] next to Data Source and select the file.
The connector looks like this after selecting a file:
Click the browse icon [ ] next to each field that you want to use in this process, then select the process field it should map to.
Continue mapping fields in this way until you have mapped all data that you want to bring in for this process item. This step ignores unmapped fields. For example, the “Attended Sessions” data in the screenshot below will be ignored.
Once you’ve mapped all of the desired fields, click Save.
You can now test the mapping to ensure it is acting as you expect.
The Generate Document app connector lets you generate a document based on data passed into the connector from the task.
For example, this connector can be used to:
- Generate a nicely formatted Order Confirmation in Microsoft Word
- Create an inquiry update that can be viewed online in HTML
- Generate a certificate of completion in PDF.
The document template must first exist in the system to be able to create and configure the App Connector for it. Details on managing document templates are found in the Communications Management Administration Guide (coming soon).
The connector configuration starts out looking like this:
Document Configuration:
Parameter Definitions
Each variable defined in the document template is a parameter that must be passed into it to create the document. Some, like “CURRENT_DATE”, “USER_ID”, and “USER_NAME” are generated automatically by the system, while others must be explicitly mapped or entered. Any variables that are not defined are left blank in the generated file.
Start defining the parameters by clicking the green Plus sign to the far right of Template Parameters in the connector.
COMING SOON
This connector logs in to a FTP site and executes one or more FTP commands. It ca be configured to retry multiple times in case of failure or an incomplete command or response.
FTP Site is a selection of an FTP site record. Click the expand icon next to any site to see or edit its full record. You can also click the green plus at the top right to add a new site record.
**Max Number of Tries **is the number of times that each FTP command defined in the connector should be retried if it fails the first time. This defaults to 1.
This differs from the Task Retry Count on the previous line, which defines how many times the overall connector can be restarted if it fails.
The Try Interval is the time in milliseconds that the connector should wait before trying a failed task again.
Cutoff Time specifies a time in 12-hour format (HH:MM am/pm) after which no further FTP commands in this task should be attempted. This could be used, for example, to ensure that no items are retrieved after a business cutoff of 05:00 PM until the connector re-starts on the next business day.
Error on incomplete commands is a flag that stops the connector from continuing to attempt FTP commands if an incomplete or erroneous command is encountered. For example, if there is a command to get a file in a specific folder and that folder is not found, no further commands would be executed.
Below this section is where you would enter the actual FTP commands to be executed once the connector successfully connects to the FTP site. Click the green plus sign to start adding the FTP commands, which will be executed in the order they are listed.
FTP Command Types
The FTP command types available are:
The “Once” types match on the first instance in the remote server and execute only on that first match. The “Repetitive” types can match on multiple instances and will act on all of them.
FTP Command Parameters
Command Parameters are optional parameters that would be entered on the FTP command line to further define the action to be taken. The parameters that can be used here are the Linux ones relating to file transfer found on the FTP man page.
FTP Folder is the path of the targeted folder on the remote FTP site, starting at the default folder defined in the connection.
Local Folder is the full path to the Actionabl folder targeted by the command.
Prepared File List is where you select or create the file(s) on the Actionabl site to be acted on by the command. In the Field List that pops up, you can create a new file list like this:
If you don’t have or want a prepared file list or if the file to be acted on is on the remote site, define it in the File List instead. Click the green plus sign to add the file.
Examples:
Retrieve all .xlsx invoices from an outbound_invoices folder on Vendor1’s site, zip them, then delete them on the remote site so they aren’t retrieved again.
Retrieve all xlsx files from the outbound_invoices folder on the site. This looks for multiple files and bring each one over in a separate FTP command until no more matching files are found.
Sync the balance_due.pdf file between the Actionabl site and the Vendor1 site. Throw an error if either of the files are missing.
The REST API connector sends a request to the defined API and ingests a response (data) or status code. The response from that request is passed into the task in Actionabl.
A REST API call can retrieve data, identify the status of a request, send data, or delete a record on the remote system, depending on how the system integrations are set up. Actionabl supports the following methods:
The API call is set up like this:
The Request Detail elements now need to be built to fully define the call. Click the green plus sign and select one of the elements to build it.
The Authorization Element
Authorization will ask for the authorization type (No Auth, Basic, Bearer, or API Key) and then will ask for the specifics to authorize using that type.
The Headers Element
Click Headers to start building the request’s headers. Add each of the key-value header pairs and a description by using the green plus sign to add a new line.
The Query Parameters Element
Click Query Params to add query parameters to the call. These are added in Key-Value pairs with optional descriptions, just like the Headers. Query parameters are most frequently used for filtering and pagination within a URL string. They are the last things parsed in the query.
The Completed Connector
Once all of the elements of the API call are built and saved, the connector looks something like this:
When you edit the Connector, you can then see and edit the contents of any of its Request Elements by clicking that section.
Always use the Test button after saving to send test data through this connector to the API and see its responses.
The SOAP API protocol is more closely based on XML and has a more rigid structure and control of datatypes than the REST protocol. As such, it’s more widely used for scenarios where standardized data is being passed between systems.
Details are coming soon!
The Code app connector is the most powerful and flexible option for experienced and technical users. It enables you to define a script that completes the actions for the connector, which can include connections to external APIs, data manipulation and transformation, and much more.
These can be Javascript or Python scripts, which are saved in folders on the file system. The connector definition points to the file to be executed.
COMING SOON
The DocuSign App Connector sends a set of documents out for signatures using a Service Profile and an ESign template you previously created.
Download Signed Documents copies the PDF of the signed documents out of the referenced DocuSign account into the download folder on the Actionabl server
A SQL app connector lets you enter a SQL query and define a database on which to run it. The output of the query is then available to the next task in the process.
The structure of the connector is this:
Aside from the actual SQL query and the database connection information, you will need to specify:
If you have defined your Jack Henry integration via a Service Profile, you can run a Jack Henry operation using this connector type.
Use the Browse icon on the Jack Henry Operation line to select from a JSON file containing the operation’s definition.
Bot Connectors
The Bot connector uses the Bot source type previously defined to run a code script in a JSON file.
COMING SOON
COMING SOON
COMING SOON
The process model is a flow that includes:
There are various ways to approach building the process model; the output of all of them is a BPMN flow, which is implemented in Actionabl to activate it. You should build your flow using whichever methodology best fits your needs and preferences.
TheProcess Modeler lets you start with a blank page and flowcharting tools, which you then place and define to build the flow. We will use this method as we build the process in this section.
Also in the Process Modeler, you can open an existing flow, then use Save As to copy it as the basis for creating a new one. This is especially useful for complicated flows where you want to change a specific section of them.
In the Process Wizard, you have three options: AI Modeler, Linear Modeler, and Template Modeler.
Image can be any flowchart image in JPEG or PNG format.
Document (COMING SOON)
Tasks are the steps that an item moves through as it works its way through a process. A task calls connectors and actions and uses rules to complete a clear goal, then moves the data resulting from those elements across the flow to the next task or decision.
Decisions (and Gateways) are special tasks that evaluate a set of data against a Decision Model or a set of task rules, which determine which flow the item should follow.
While the other elements are built before starting to build the process model, Tasks and Decisions are created while you build it.
When you open a new process model, you’ll see the process configuration at the bottom and a default Start Event icon on the canvas.
Start by adding an ID and Name for the process.
Define any parameters you know you’ll need at the process level (you can always build and fill these in as you go or at the end before deploying).
Click the Process Configuration settings icon to set up defaults like a default Service Profile or email account that the tasks should use.
At any point, you can Maximize, Expand, or Collapse the configuration section at the bottom to make more room to lay out your process flow.
In the Process Fields section, add all of the data fields that should be available to this process as inputs OR as outputs. There are three ways to do this:
For each field that you add to the process, you can:
Click Save As in the top right menu and name the process to save your work so far. Remember to do this frequently as you work!
Click the default Start Event icon on the canvas. It becomes active and the configuration panel at the bottom now relates to it.
Add the configuration settings for this task, which will follow the item it creates through the process:
Select the Connector that this start event will use.
If this process can have multiple start events indicate whether this is the default one. For example, if invoice auto-payment can be started manually with a form OR by receiving an invoice via email, indicate which one of these is the default.
If the start event is something requiring a user interface, such as a form or user selection, click UI Configuration.
In the Start Event and in every other task, select the Task Input fields that will be used as Input and Output, as well as any Rules that should apply to this task. As you select the fields, they are automatically moved to the top of the Task Input list. If an input is required, click its RQD box.
Add the first Task in the flow. In this case, we’re going to add an RPA that will check the invoice to determine if it’s eligible for auto payment.
Decisions can be handled in two ways:
Decision Tasks use decision models that you built using the Decision Modeler. These can include complex rules and have multiple output paths.
For example, this decision task looks at a set of 6 query criteria and decides how to assign the task, with three possible assignments as the output (auto1, auto2, or team1).
Exclusive Gateways, by contrast, use simple task rules and can have only 2 output options - a “true” path and a “false” path.
To build complex rules that assess items against multiple criteria and route them within the flow, use the Decision Modeler.
Stages represent a set of statuses that an item can have as it moves through a process. For example, in the “Pay Invoice” stage, an item might have either manual_pay or auto_pay as its status, but in either case it has been approved and is waiting for a payment action to take place.
Groups are an easy way to visualize the stages in a process, but they don’t have an active function. They are represented by dashed lines in the process model.
The arrows that connect tasks to each other represent the flow of items.
Flows may contain logical expressions that determine whether an item can use them, such as autopay=false in the example below. They may also have visible Names that can help a user understand the diagram, such as “No” in this example. You can also select a Color for the flow, if desired.
The choices of Default Path and Error Path as flow behaviors work together with the Expression to guide an item’s flow through the process.
Every process requires an End Event, just as it had a Start Event.
While there may be multiple resolution tasks at the end of different flows, such as an invoice rejection email being sent vs an invoice payment confirmation, all of those resolution tasks must flow into an End Event. This signals to the process that it is complete and should stop processing.
The process report can be generated by clicking Report at the top of the process manager view.
The Process Report is a detailed, textual review of the process, which includes a list of all of the fields available to it, each of the Tasks in it, which connectors are used, and their configurations. It is an invaluable tool in troubleshooting and in communicating/teaching about a process.
The report generated is a PDF, which you can download or print from the dialog box when it opens.
As you’re building your process, you should be testing each element to make sure that it works as you expect. Using the Test command in the menu for the items gives you a quick and reliable way to do this.
As the process comes together, there are pieces that you cannot test individually, such as the flows and logic. Before deploying to your production environments, we recommend using the Process View in your test environment to manually start the process using test items that you create for each of the scenarios.
It’s important to make sure that your test items cover each of the decision flows and rules within the process.
Once you have built and tested the process flow and are ready to use it, clicking Deploy in the top menu makes it active.
After you click Deploy, you’ll receive a popup to configure the server, schedules, etc.
Depending on the type of Start Event you’ve selected, the process will either:
You can see the process’ status in the Control Center -> Automation Manager dashboard, where you can pause or restart a running process.