Lifecycle Rule

Lifecycle rules are the easiest way to add automation to your solution. Lifecycle rules have 2 parts - Lifecycle events and Lifecycle actions.

Lifecycle events are generated every time any change occurs in the system. For example when you update a lead - a lead being a process - an event called process:update:post is generated carrying the details of the change.

So we can write rules to execute automatic lifecycle actions basis lifecycle events. For example we can say whenever a lead is updated send a notification to the lead assignee. Here send-notification is the lifecycle action we want to execute.

To summarize, the following is a lifecycle rule

When a lead is updated, send a notification to the assignee

• Lifecycle Event -> When lead is updated
• Lifecycle Action -> Send a notification to the assignee

Event Conditions

More often than not we would want to add some conditions to figure out when we want to run a rule. Continuing the previous example - it would be far more useful to notify a lead assignee when important updates happen to the lead. For example

When a lead's state changes to converted, send an email to the assignee

Here we added an extra condition called "when the lead's state changes to converted" - These extra conditions / criteria are implemented via event conditions that we can add to any rule. Conditions follow standard rule engine grammar

Action Definition

Action definition is where we configure the exact parameters needed to run an action. For example here

When a lead's state changes to converted, send an email to the assignee

we would want to define what goes into the email as

{
  "emailSubject": "{{process.data.lead_id}} has been conveerted",
  "emailBody": "Hi {{user.firstName}}, congratulations your lead {{process.data.lead_id}} is now converted."
}

Here we are able to exactly configure what the action is going to be in the context of the event which in this case is a lead update. In the action definition you will be able to access all data pertaining to the update like process details, user details, etc...

Tagging

Lifecycle rules should be tagged against a relevant meta entity like procedure, entity or statetask.

Sync/Async

Rules can be processed in sync or async manner with the event. Ordering currently is not guaranteed for async rules.

Populate

many times we need to populate the original event for extra info. The main concerns around populating are

• latency - too many populates = too many data fetches = slower rules
• more complex rules

Currently populate is done at 3 levels

• process-event
  • all task events get populated with populatedTask
• process-action
  • all events with the correct populatePath definition gets populated in-situ - original event object gets mutated
• action implementation
  • individual actions themselves also populate data usually into a key called _meta

List of events

• api-check:post
• booking:update:post
• call:create:post
• call:create:pre
• call:update:post
• email:received:post
• form-response:create:post
• process:allocate:post
• process:create:post
• process:create:pre
• process:state-change:post
• process:update:post
• process:update:pre
• record:create:post
• record:update:post
• task:create:post
• task:create:pre
• task:update:post
• task:update:pre
• upload-job:complete:post
• user:login:post
• user:logout:post
• webhook:inbound:post

List Of Actions

• process:start
• record:create
• record-process:create
• process:complete
• process:update
• process:bulk-update
• process:find-one-and-update
• task:create-from-statetask
• task:allocate
• task:bulk-update
• record:find-and-update
• script:run
• task:webhook-task-external
• process:webhook-process-external
• call:webhook-call-external
• task:webhook
• process:bulk-find-and-complete
• process:update-using-rule
• process:modify-query
• external-api:call
• call:link-record-and-process
• notify:email
• notify:sms
• notification:create
• external-data-store:push