Skip to main content

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