On this page

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.

Workflow functionality

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
Workflow rules can be applied to activities, service requests, jobs, subscriptions and reward offers.

Setting Up Workflows

Foundation > Workflows

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 Approval 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.

Alerts, approvals, and webhook actions are defined through definitions. Once configured the definitions can be used in multiple workflow rules.

Alert definitions

Alert definitions determine the content, media, and recipients of automatic alerts resulting from workflow rules.

Alerts can be communicated for activities, jobs, service requests, subscriptions, leads and reward offers. Each alert is related to a specific entity.

Once the alert definition is configured, add it to a workflow rule through which it can be triggered. 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.

Definition fields

The table describes the sections of Alerts Definitions Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Name: Used to identify the definition in workflow rules. Life Cycle State: Can be 'Effective' (the state of new definitions) or 'Not Effective' (added to workflow rules but not triggered). Once the definition is saved, use Set as Effective from the Actions menu to change its state.
Settings
Type: The media used to send the alert can be email or SMS. The Entity that is communicated through the alert can be one of the following: Activities Jobs Leads Service Requests Subscriptions Reward Offers Subject (of email sent to the users) Content (of the email or SMS; restrictions on character count apply, as specified in the active Communication Definition for each type of media) Alert tags can be used in the subject and content. Tags are auto-suggested and can be selected by typing '#'.
Recipients
Defines users that will receive the alerts created through the definition. Enable to select and alert the: 'Created by User' 'Updated by User' 'Assigned to User' (for assignable entities only, i.e., activities, jobs, service requests) 'All Users Belonging to the Assigned to Unit' (for assignable entities only, i.e., activities, jobs, service requests) 'Specific Users' 'Users Belonging in Specific Units'.
Workflow Rules (read-only)
Displays a list of all the workflow rules that include the specific alert definition as one of their actions.

Approval definitions

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. Approval requests can be created for activities, jobs, service requests, subscriptions and reward offers.

Definition fields

The table describes the sections of Approval Definitions Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Name: Used to identify the definition in workflow rules. Life Cycle State: Can be 'Effective' (the state of new definitions) or 'Not Effective' (added to workflow rules but not triggered). Once the definition is saved, use Set as Effective from the Actions menu to change its state.
Settings
The Entity that will require approval can be one of the following: Activities Jobs Leads Service Requests Subscriptions Reward Offers Subject (displayed on approval) Requested Number of Approvals: Defines the number of approved, rejected or canceled approvals that are necessary to unlock (for editing) a record pending approval.
Authorised Users
Defines users that are authorized to approve, reject or cancel approval requests. Define users by selecting the: 'Specific Users' (several can be defined) 'Users Belonging to Specific Units' 'Users Assigned to Specific Security Profiles'
Workflow Rules (read-only)
Displays a list of all the workflow rules that include the specific approval definition as one of their actions.

Webhook definitions

Webhook definitions are business 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.

Once the webhook is configured, add it to a workflow rule through which it can be triggered. 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.

Definition fields

The table describes the sections of Webhook Definitions Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Name: Used to identify the webhook definition in workflow rules. Life Cycle State: Can be 'Effective' (the state of new definitions) or 'Not Effective' (added to workflow rules but not triggered). Once the definition is saved, use Set as Effective from the Actions menu to change its state.
Settings
The Entity that will be communicated through the webhook can be one of the following: Activities Jobs Leads Service Requests Subscriptions URL: The address that the webhook will be sent to. Fields Set: The fields to be sent through the webhook. All the fields that are retrieved through the 'Show Web API method' of the related entity are available. The fields to be sent are defined manually, by specifying the comma-separated name of each field (as through the Web API). If this information is not specified, then all the available fields will be sent. 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. Only keys whose URL endpoint matches the webhook's URL and whose type is set to 'Webhook Key' are retrieved in the search.
Workflow Rules (read-only)
Displays a list of all the workflow rules that include the specific webhook definition as one of their actions.

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 the following modules:

Activities
Jobs
Leads
Service Requests
Subscriptions
Reward Offers

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.

Workflow rule fields

The table describes the sections of Workflow Rule Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Name Life Cycle State: Can be 'Effective' (the state of new definitions) or 'Not Effective' (added to workflow rules but not triggered). Once the definition is saved, use Set as Effective from the Actions menu to change its state.
Settings
The Entity to which the rule is applied. Each rule is associated with one of the following entities: Activities Jobs Leads Service Requests Subscriptions Reward Offers Processing Order: Workflow rule actions are classified as 'updates' and 'other actions'. The processing order defines whether the entity that triggers the rule is updated first and then acted upon or vice versa. The available options are: Updates First and Then Any Other Actions. Any Other Actions First and Then Updates 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). Priority: Levels (Low, Medium, High) that determine the order in which rules are applied to each entity. Rules with the same priority are applied in random order. Entity Types for which the workflow rule are triggered, evaluated and applied. The entity determines which types are available for selection. Multiple types can be defined.
Triggers
Events that trigger the rule. Multiple triggers can be selected, including: 'On Create' 'On Update' 'Through Web API'
Conditions
A set of criteria that should be met in order for the workflow rule to be applied. Multiple conditions can exist for each workflow rule. The workflow rule is applied when: AT LEAST ONE CONDITION IS MET or ALL CONDITIONS ARE ME The available options for each condition depend on the condition type. Select a type for each condition to bring up available options. When Specific User of Unit Makes a Change: Used to define one or more users or units. The condition is available when the trigger is set to 'On Create' or 'On Update'. When Specific Field Changes: Used to define fields that are modified when the record is created or updated. When Specific Field Contains Specific Value: Used to define field values (one value can be defined per field). When Specific Field Changes from a Value to Another: Used to define the value before and after the update. Where more than one row is defined for each condition at least one should be met.
Actions (Applied according to the workflow rule if conditions are met. Multiple actions can be applied for each rule and their order is determined by the workflow rule's processing order settings.)
Update Information	Determines the value that fields should be updated to as a result of the workflow rule. Multiple fields can be selected for an update, as long as they are not conflicting. Field: Available fields depend on the selected entity. Value (for each field)
Send Alerts	Alert definitions that will be triggered to send alerts to the users. Select an existing definition or create a new one.
Set Approvals	The approval definitions that will be triggered to create approval requests. Select an existing definition or create a new one.
Trigger Webhooks	The webhook definitions that will be triggered to create webhook requests. Select an existing definition or create a new one.
Schedule Activities	The type of activities that will be scheduled for the new entry when the conditions are met. Multiple activity types can be selected resulting in multiple activities being scheduled every time the rule is triggered. Applicable for: Jobs Leads Service Requests Subscriptions 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.

Related configuration areas

Mandatory modules must be configured for the workflows module to work.

Manual Link	Area	Description	Configuration
Security Management	Secret Key	Mandatory in order to create webhook definitions.	Mandatory
Security Management	Automatic Collaboration Rules	Required in order to automatically assign a scheduled activity to a user or unit once it is created.	Mandatory (if activity scheduling is enabled through workflow rules).

Using Workflows

Foundation > Workflows

A workflow is triggered when an event defined in an effective workflow rule and which meets rule conditions occurs. For example, when a new job is created (event) of type 'new subscription' (condition) an alert is sent to the installer (action). No user interaction is necessary.
The following actions can be carried out:

Require user interaction	Do not require user interaction
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.	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.

Managing 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'.

The table describes the sections of Approval Requests Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Entity and Entity Number: The name and unique ID of the entry that must be approved. The Life Cycle State of the request can be 'Pending', 'Approved', 'Rejected' or 'Cancelled'. Entries with a request in any state except 'Pending' can be modified. Unified Code: A unique identifier that is used to group approval requests created for an entry by the same workflow rule and approval definition. Approval Definition that was triggered by the workflow rule and created the request. Workflow Rule that triggered the approval request. Subject of the approval request as defined in the approval definition.
Authorised Users
The list of users that are authorized to approve, reject or cancel the record.
Response Information (for 'Approved', 'Rejected' or 'Cancelled' requests)
Response: Provided by the user and can include reasons for rejecting or canceling the request. Responded by (user) Responded on (date)

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.

Managing approval requests from the entity page

Requests can be approved, canceled or rejected from the entity's Data Entry page. All outstanding requests must be handled before an entry can be amended.

For example, a service request with several 'Pending' approvals can be handled by using the respective action on the service requests Data Entry page. Each user can approve, reject or cancel a single approval per entry.

From the Actions menu select one of the PENDING (X) APPROVALS actions below:
1. APPROVE
2. REJECT
3. CANCEL

Approval requests for an entry are displayed in its Data Entry page under Action panel > View History.

Managing 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.

The table describes the sections of Webhook Requests Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Entity and Entity Number The Life Cycle State of the webhook can be 'Successful' or 'Rejected'. Rejected webhooks can be resent. Error Code and Error Description (in case the webhook was not successfully received by the third-party system) URL: Used to send the webhook. Secret Key: Used for authentication by the third-party system. Webhook Definition that was triggered by the workflow rule and created the webhook. Workflow Rule that triggered the creation of the webhook. Fields Set: The set of fields included in the information sent to the third-party system Request: The complete request sent by the webhook, using the URL and Fields Set.

Main Information

Entity and Entity Number

The Life Cycle State of the webhook can be 'Successful' or 'Rejected'. Rejected webhooks can be resent.

Error Code and Error Description (in case the webhook was not successfully received by the third-party system)

URL: Used to send the webhook.

Secret Key: Used for authentication by the third-party system.

Webhook Definition that was triggered by the workflow rule and created the webhook.

Workflow Rule that triggered the creation of the webhook.

Fields Set: The set of fields included in the information sent to the third-party system

Request: The complete request sent by the webhook, using the URL and Fields Set.

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.

Managing 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.

The table describes the sections of Alerts Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Type: 'Email' or 'SMS' Entity and Entity Number Life Cycle State: Can be 'Successful' or 'Rejected'. Rejected webhooks can be resent. Recipient Recipient Email Address or Recipient Phone Number Alert Definition that was triggered by the workflow rule and created the alert. Workflow Rule that triggered the creation of the alert. Subject of the alert email. Content: The information included in the alert. Error Code and Error Description (if the alert was not successfully sent to the recipient).

Main Information

Type: 'Email' or 'SMS'

Entity and Entity Number

Life Cycle State: Can be 'Successful' or 'Rejected'. Rejected webhooks can be resent.

Recipient

Recipient Email Address or Recipient Phone Number

Alert Definition that was triggered by the workflow rule and created the alert.

Workflow Rule that triggered the creation of the alert.

Subject of the alert email.

Content: The information included in the alert.

Error Code and Error Description (if the alert was not successfully sent to the recipient).

Workflows Business Examples

New subscription order workflow

New Subscription Order

Scenario 1

Company ZX 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' fulfillment 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.

Notes

If you are using a previous release, view CRM.COM Release Changes.
Use the WEB API to create and manage workflows from an external system, such as a customer portal. Refer to following WEB APIs for a comprehensive list of available actions.

Glossary

CRM.COM Term	Definition
Activity	A small task or action that is either stand-alone or must be completed as part of a larger project.
Service Request	Request used to register problems that customers experience with their products and subscriptions and to check whether products are under warranty.
Job	A small project initiated by the operator for customers, involving the delivery and billing of services, products and activities. Customer requests and orders, such as that for a new subscription, can be initiated and registered through a job.
Subscription	A selection of customer services billed on a recurring, usage or one-time basis.
Reward Offer	An offer that awards rewards participants subject to award and spend conditions.
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.

Overview

Workflow functionality

Setting Up Workflows

Alert definitions

Definition fields

Approval definitions

Definition fields

Webhook definitions

Definition fields

Workflow rules

Workflow rule fields

Related configuration areas

Using Workflows

Managing approval requests

Approving a request

Cancelling an approval request

Rejecting an approval request

Deleting approval requests

Managing approval requests from the entity page

Managing webhook requests

Resending a Rejected Webhook Request

Managing alerts

Workflows Business Examples

New subscription order workflow

Glossary

Related Links