Overview

A workflow is a predefined sequence of steps necessary to complete a task.  Business specific workflows are supported by a set of rules that automate processes and trigger system actions when predetermined events occur. In CRM.COM Workflows are triggered when specific events are executed and can consist of a series of actions including

• The update of an entry
• The notification of users regarding events 
• Passing information to third-party systems by using webhooks
• Requesting the approval of new or modified entries before further processing is allowed
• Scheduling of activities

You can set up workflows for the following modules

• Accounts Receivable
• Financial Transactions (Credit Note, Invoice, Invoice Cancellation, Payment, Payment Cancellation, Refund, Write Off)
• Wallet
• Wallet Transaction
• Activities
• Job
• Lead
• Service Request
• Contact Information
• Reward Offer
• Subscription
• Ad Hoc Discounts

Setting Up Workflows and Core Processes

Workflow rules are used to define workflows and see their execution through.  Rules are triggered when an event, such as the update or creation of a new CRM.COM entity, takes place. For example, in a new subscription, conditions defined in the workflow rule such as setting the billing term to 'Prepaid', can be set to trigger the following series of actions:

• Update Information on the subscription that triggered the workflow.
• Set Approvals  requests by specific users before the subscription can be amended (as defined in the approvals definition).
• Schedule Activity that is necessary to complete the task, such as an appointment for installation.
  
• Send Alerts  by email or SMS prompting users to take action (as defined through alert definitions), e.g., an email to installers for an appointment.
• Trigger Webhooks  that pass information to a third-party system (as defined in the webhook definition) such as subscription information to a portal requesting a subscription.
  

While update of information and activity scheduling can be done directly from the workflow the rest of the actions need additional configuration.

Lets see how you can set up each area before moving to workflows.

Back to top 

Alert Definitions

Alerts are used in order to communicate information to CRM.COM users, either through email or SMS.

Alert definitions determine the content, media, and recipients of automatic alerts resulting from workflow rules. Each alert is related to a specific entity. 

On the Alert definition you must provide the entity for which you want to send notifications for and select whether it should be sent via email or SMS . The content can be directly provided on the Alert definition (restrictions on character count apply, as specified in the active Communications for each type of media). You can use Alert Tags which can be selected by typing '#'. 

Additionally you can define the recipients of the notification which can be either groups of users defined through Units or specific users.

Once the alert definition is configured activate it by Actions > Set as Effective and add it to a workflow rule through which it can be triggered.

Testing Alerts

 Use Test Connection from the Actions menu to make sure that the emails will be sent successfully.  Provide your own email address and the entry for which the alert definition has been set up.  Click SUBMIT TEST to see whether the connection was successful.

Back to top 

Approval Definitions

Approvals are used to block a specific record from being edited unless it is approved by an authorised user.

Approval definitions are business rules that determine the approval requests that should be generated and the users that are authorized to approve further amendments on an entity. Once the definition is configured, add it to a workflow rule through which it can be triggered.

Each approval is related to a specific entity.  

When setting up an approval it is important to first select the Entity which will need to be approved before further processing is allowed. An approval subject on every approval created allows users to know what the approval is for. Additionally the number of approvals that are necessary to unlock (for editing) a record pending approval must be provided. The users authorized to approve, reject or cancel approval requests must also be provided in Authorised users and can be either groups of users defined through Units or specific users.

Once the approvals definition is configured activate it by Actions > Set as Effective and add it to a workflow rule  through which it can be triggered.

Back to top 

Webhooks

Webhooks are used in order to pass information to third-party systems, without being integrated with CRM.COM. 

Webhook definitions provide rules that are used to provide information associated to the webhook to be triggered when used in a workflow rule, such as the information and the URL that it should be sent to.

To set up a webhook definition, provide the Entity for which the webhooks should be generated, the URL where the webhook will be sent to. A secret Key must be selected. This is a key registered to a specific URL endpoint and used by webhooks to generate a code used by third-party systems to authenticate received data. Only keys whose URL endpoint matches the webhook's URL and whose type is set to 'Webhook Key' are retrieved in the search. You can setup secret keys at Foundation / Security Management / Manage Secret Keys.

In the Fields Set section provide the fields (comma separated) which will be returned from the webhook. The available fields are the ones available from the respective 'Show WEB API' of the entity you are creating the webhook definition for. For example, if you are creating a webhook for accounts receivable, the fields included in the Fields Set can be any of the fields in the response of GET accounts_receivable/show

Once the webhook definition is configured activate it by Actions > Set as Effective and add it to a workflow rule  through which it can be triggered.

Testing Webhooks

Use Test Connection from the Actions menu to confirm that the webhook is working properly.  Provide an entry of the entity for which the webhook definition has been set up. Click SUBMIT TEST to see whether the request and response to be created are displayed, confirming the test was successful (the request consists of the data included in the Fields Set). If the test failed, a message appears that the provided information was wrong.

Back to top 

Workflow Rules

Workflow rules support business workflows and automate tasks required to complete business processes by triggering conditional system actions. Workflow rules can be set up for various modules.

Once you have set up alert, approval and webhook definitions required for the desired workflow, set up the workflow rule that will start the workflow.

When setting up a workflow rule you must provide the entity for which the workflow is for. If the entity has multiple types and you would like to only create a workflow for a specific type then you can select it at Entity Type. As through the workflow a record can be updated on top of any other actions carried out on a record you can define the order by which these actions will take place, in case they are interdependent by defining the Processing Order. For example, select 'Updates First and Then Any Other Actions' if the workflow rule stipulates that the task should be assigned to a particular user (i.e., 'Assigned To User' field should be completed first, as defined in the Update Information section) and then the user notified to handle the task. Select 'Any Other Actions First and Then Updates' if an alert should be sent to the user first, and then the status of the task updated to 'In Progress' (to inform the user that the task is being processed).

Additionally you can set Priority Levels (Low, Medium, High) that determine the order in which rules (in case multiple workflow rules are in place) are applied to each entity. Rules with the same priority are applied in random order.

As explained above the workflow will start based on a given trigger. Multiple triggers can be selected, including the creation or update of a record on by calling the GET workflow_rules/trigger WEB API.

You can then set conditions which must be met in order for the workflow to be set off.

And finally you need to define the actions that will take place by the workflow. The available options are to:

• Update Information: When you select to update information you can provide both the field to be updated and the value it should take
• Send Alerts: Select one of the configured alerts for the selected entity
• Set Approvals: Select one of the configured approvals for the selected entity
• Trigger Webhooks: Select one of the configured webhooks for the selected entity

• Schedule Activities: When scheduling activities you must select the activity type which will be created. If you select multiple activity types it will result in multiple activities being scheduled every time the rule is triggered.

  • Activity assignments must also be configured in Automatic Collaboration Rules (ACR), which will automatically assign an activity to a user or unit as soon as it is created.

  • Automatic scheduling of activities does not apply to jobs whose fulfillment method is 'Based on ordered items', as they cannot have more activities planned than originally ordered.

 Back to top

Using Workflows

A workflow is triggered when an event defined in an effective workflow rule and which meets rule conditions occurs. The result of the workflow depends on the  actions enabled through the definition. When the workflow is completed depending on the actions carried out some will require further actions possibly by a user:

• Create approval requests - A user must approve, reject or cancel the request for the record to be editable.
• Schedule activities - The activity's 'Assigned to' user must handle the task.

The following actions will not need user interaction

• Update information such as 'Status' on an entry.
• Send alerts to users of the record being created or modified.
• Trigger a webhook to provide record information to a third-party system.

Back to top 

Using approval requests

An approval request is a mechanism that is used to control the creation and update of entries in the system by requesting authorization from specific users. One or more approval requests can be created for each entry, according to the configuration of the approval definition.  Requests are created in a 'Pending' life cycle state and are subsequently 'Approved', 'Rejected' or 'Cancelled'.

Approving a request

To approve a request, navigate to the approval requests Data Entry page and click on Approve from the Actions menu. Provide a response and SAVE the request. Approved entries can be edited.  Provided there are no other 'Pending' approval requests for the entry, the system will inform the user that the entry associated with the request will become editable.

Cancelling an approval request

Canceled requests enable the editing of the related entry, as long as the entry does not have another 'Pending' request.  

To cancel a request, navigate to the approval requests Data Entry page and click on Cancel from the Actions menu. Provide a response and SAVE the request. Provided there are no other 'Pending' approval requests for the entry, the system will inform the user that the entry associated with the request will become editable.

Rejecting an approval request

Rejected requests enable the editing of the related entry, as long as the entry does not have another 'Pending' request.

To reject a request, navigate to the approval requests Data Entry page and click on Reject from the Actions menu. Provide a response and SAVE the request. Provided there are no other 'Pending' approval requests for the entry, the system will inform the user that the entry associated with the request will become editable.

Deleting approval requests

Approval requests that are not 'Pending' can be deleted.  Use DELETE from the Actions menu on the Data Entry page.  Several requests can be selected in the approval requests Summary page and deleted simultaneously. 

Back to top

Using webhook requests

Webhooks are used to send information to a third-party system defined in the URL of the webhook. The information sent is the same as the response displayed by the 'Show' WEB API of the respective entity.

Resending a Rejected Webhook Request

Rejected webhook requests can be sent again using Resend from the Data Entry page Actions menu, resulting in a new webhook request.  If the new request is successful the original request is deleted. If the new request is also rejected, the original request will be updated with the latest error code and description.  

Using alerts

Alerts are communications that are triggered by the system.  Alerts inform users regarding tasks they have been assigned or system changes that could potentially affect them. Alerts can be created for activities, jobs, leads, service requests, subscriptions and reward offers.  Alerts use Alert Tags to dynamically generate information based on entity data communicated through the alert. 

Back to top  

Business Flows