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

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.

Back to top

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.

Back to top 

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.

Back to top 

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

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

Back to top 

Related configuration areas

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

Using 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:

Back to top 

Managing 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 

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.

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

Back to top

Managing 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

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.  

Back to top 

Managing 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

Workflows Business Examples

New subscription order workflow

Back to top