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.

Let's see how you can set up each area before moving to workflows.

Back to top

alertsAlert Definitions Turquoise16pxfa-question-circle

Foundation / Workflows / Set up and Manage Alerts / Set up 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

approvalsApproval Definitions Turquoise16pxfa-question-circle

Foundation / Workflows / Set up and Manage Approvals / Set up 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 approving, rejecting or canceling 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

webhooksWebhooks Turquoise16pxfa-question-circle

Foundation / Workflows / Set up and Manage Webhooks / Set up Webhook Definitions

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 set up 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

workflowsWorkflow Rules Turquoise16pxfa-question-circle

Foundation / Workflows / Set up 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 , 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 fulfilment method is 'Based on ordered items', as they cannot have more activities planned than originally ordered.

Recommended additional setup

In addition to the webhook, alert, approval definitions the following may be configured for workflows to operate at its full capacity.

Network and Security Setup
- Secret Key: Mandatory in order to create webhook definitions.
- Automatic Collaboration Rules: Required in order to automatically assign a scheduled activity to a user or unit once it is created.

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

Foundation / Workflows / Set up and Manage Approvals / Manage 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

webhookUsing webhook requests

Foundation > Workflows > Set Up And Manage Webhooks > Manage 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.

To keep track of successful and unsuccessful calls, enable 'Log All Webhook Requests' under Logging Method in the webhook definition.

alertUsing alerts

Foundation > Workflows > Set Up And Manage Alerts > Manage 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

New subscription registration workflow

Scenario

Aluxsat Co. follows the workflow below when a new subscription order is placed.

The call center agent receives an order for a new subscription.
The sales manager must accept the job order for it to progress.
Once the job is accepted, an installer must install the necessary hardware.
The installer activates the subscription after the installation is completed.

Solution

Requirement	Solution	Required Configuration
The call center agent receives an order for a new subscription.	A job of type new subscription should be registered in the system.	A job type with a 'New Subscription' fulfilment scope must be present in the system.
The sales manager must accept the job order for it to progress.	The sales manager must approve the request created for the job. Once the request is approved the manager should set the job status to 'In Progress'. If the approval request is rejected the job status is set to 'Cancelled'.	An approval definition for jobs must be configured with a 'number of requested approvals' set to '1' and the sales manager set as the 'authorised user'. A workflow rule must be configured for jobs so that the approval definition is triggered every time a job of type 'New Subscription' is created.
Once the job is accepted, an installer must install the necessary hardware.	Once the job's status is set to 'In Progress' the system schedules an activity of type 'New Installation'. The local installer is sent an email regarding the new installation.	An 'Installation' activity type must be configured. A job workflow rule must be configured so that an activity of type 'Installation' is created when a job of type 'New subscription' is updated and the job life cycle state is changed to 'In Progress'. An activity alert definition must be configured, which informs the 'Assigned to User' (by email) that a new installation task has been scheduled and forwards the relevant subscriber information. An activity workflow rule must be configured so that an activity of type 'Installation' is created whenever the alert definition is triggered.
The installer activates the subscription after the installation is completed.		Integration using CRM.COM WEB APIs is required in order to update the status of the activity and job.

Glossary

CRM.COM Term	Definition
Units	A body of users that belong on the same team and follow identical business processes.
Activity	A small task or action that is either stand-alone or must be completed as part of a larger project.
Secret Key	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.

FAQ

I have set up a workflow rule where an activity will be triggered if the status of the Service Request is set to 'In progress' however when triggered only the status of the service request is updated.

The reason that the activity is not triggered is because the system tried to create the activity before updating the status of the service request and failed because the service request status was not set to 'In Progress'. The order by which processing of actions is done, can be controlled using the 'Processing Order' on the workflow rule. In this case you would need to select 'Updates First and Then Any Other Actions' so that the scheduling of the activity action will be done after the service request status is already updated.

I am trying to set up a webhook definition but I cannot get an secret keys to choose from.

When creating a webhook definition the list of secret keys you can choose from must be associated to the URL endpoint you have set in the definition.

You first need to create the secret key for the specific URL through Foundation / Security Management / Manage Secret Keys and then create the webhook.

Useful Links

falseV4Manualfalselabel = "global" and space = "V4Manual"global

Browser not supported