An introduction to Offers (workflow management)

A brief explanation of what "offers" really mean and how they work in the UrbanPiper platform

Written By Anirban Majumdar (Super Administrator)

Updated at August 20th, 2020

Before we begin, there's an important distinction needed to be established w.r.t "Offers" in the UrbanPiper system:

An "Offer" hasn't got anything to do with the traditional meaning of the word offer. While the concept of Offers was intially developed to model real world offers, but it soon evolved into something different, which has very less to do with offers

It is best to think of "Offers" in the UrbanPiper system as a Workflow Management System.

What is a Workflow Management System?

A workflow, in the context of the UrbanPiper system, signifies a series of actions that need to be taken based on an event

As an analogy, think of an event like a doorbell going off. When this event occurs, you need to take the following actions: reach for the door, see through the keyhole for the person and open the door.

Besides the event and the actions, there is another important component of a workflow — rules. A rule is meant to check on a condition based upon which future actions may or may not be taken.

In our earlier analogy of the doorbell, think if there was a rule like so:
Open the door, only if you know the person

So, it would be ideal to have this rule inserted between the see through the keyhole and open the door actions.

A simplified overview of this workflow system can be depicted as such:

Offers – a detailed look

"Offers" in the UrbanPiper platform are just a Workflow Management System which is made up of the following 3 primary parts:

  1. Trigger event – sets off the workflow.
  2. Actions – things to do based on the event.
  3. Rules – things to check before executing the actions.

Besides these 3 components that make up a workflow, another important concept needs to be understood, and that is of Contextual data

Contextual data is the information that is available in the "context" of an event. This data is then used by the rules and actions to execute their logic.

To give some examples, the contextual data for say an event like a customer-purchase would include things like:

  • customer identifier
  • purchase amount
  • purchase time
  • store at which the purchase was made
  • discount amount (if any)
  • discount coupon (if any)
  • items purchased
  • store operator identifier
  • taxes 

This data is now available to all the rules and actions that are configured to be executed as part of a workflow triggered by a customer-purchase event

The following image provides a clear overview of the various parts that make up a workflow:

To wrap-up, here's an explanation of the concepts associated with a workflow (offer) in the UrbanPiper system:

  • Event – the trigger that sets off the workflow execution. The UrbanPiper platform emits many such events while completing some task. Examples of events are: customer purchase, wallet balance updated, user account verified, online order placed, online order completed/cancelled, etc. For an exhaustive list of events, please refer to this article.

  • Contextual data – the information available in the context of an event. This data is available to all rules and actions configured as part of the workflow.

  • Global rules – these are conditional checks that are executed before any of the actions are executed. If any of these rule checks fail, then none of the actions will be taken. There can be multiple rules configured at the global level. If even a single rule fails, the execution of the workflow will be aborted. The rules execute in an order, which is determined by a parameter —apply order — associated with the rule. A lower apply order value indicates that the associated rule will execute earlier than another rule having a higher evaluation order value.

  • Actions – these are also referred to as Piper Actions. Each action signifies a discrete task that needs to be done as part of the workflow. These tasks can be things like: credit reward points, deduct wallet balance, send an SMS/e-mail/app notification, etc.
    A workflow can have multiple actions associated with it. Multiple actions will be executed in a chainone after the other— in an order that is determined by the evaluation order associated with it. The evaluation order affects the execution order of actions in a manner similar to what apply order does to multiple rules.

  • Private rules – while global rules operate before any of the actions are executed, and if any of them fails, then none of the actions will be executed; private rules, on the other hand, are tied to a single action. If any of them fails, then it affects only the action to which they're associated. The other actions will still be executed even if this action is skipped.

  • Parameters – for each rule or action, some degree of configuration needs to be done. In these configurations, we set the values for certain variables which will be used by the rule or action to complete its execution. These variables are referred to as parameters.
    An example could be that when we define a rule to check whether a purchase is of a value greater than 200, then we need to set a parameter PURCHASE_AMT_THRESHOLD to the value 200 as part of configuring the rule.

Use Cases

Some of the use cases for an offer are given below:

  • Use Case 1: A merchant wants to provide a cash back of 50 Rs for online orders.

    Solution:  Here, the trigger event will be a Customer Purchase, for which you may specify rules to check if the Purchase Amount has reached its threshold and also, check if the purchase has been made online. The actions associated with these rules can be mentioned as Update Balance, which consists of adding 50 Rs to the customer's account and rounding off the balance. This is triggered when the rules specified by the user is satisfied.
    The process flow diagram given below will illustrate this use case:

  • Use Case 2: A merchant wants to provide referral bonus of Rs 100 to the referrer and the referee for the first order.

    Solution: Here, the trigger event will be an Order Complete, for which you may specify a rule to check if this is indeed the first orderIf this rule is satisfied, then the Action associated with it, Process Referral is applied. By doing so, the referrer and referred are given Rs 100 and a notification regarding this is sent out to them.
    The process flow diagram given below will illustrate this use case:


In the next section, you will learn how to define, execute and set up an offer. 

Was this article helpful?