Workflow Rules

The Workflow Rules are powerful tool for automating RMA processing. Each event, each stage, which RMA passes, can be hooked using these rules.

Each Rule contains a set of conditions and automated actions. Whenever RMA is changed, our extension checks all Rules, and if conditions are met - corresponding action is triggered.

For example, when new RMA arrives, all the department members can be alerted. If support team member answers to the RMA Request, its status can be automatically changed to Approved or Rejected. If customer makes no reply for 3 days, a reminder to him can be sent.

Workflow Rules also can enhance auto-replies in Statuses, usage of Custom Fields, and even enhance your email communication. The possibilities are wide enough to support RMA policy of any complexity.

All rules are located in their dedicated Grid at RMA -> Workflow Rules. There you can Change Status (e. q. activate or deactivate them) and Delete them using mass-actions. New Rules also are created there.

Please, check examples of Workflow Rules before creating your own one.


How to create a Workflow Rule

Visit RMA -> Workflow Rules and press the button Add New to create a new Workflow Rule. You will be brought to the Creation page with the following tabs:

General Information

This tab contains the most basic properties of the rule.

  • Rule Name - sensical name of the rule. Carefully selected name will help you to determine, for what task rule is created.
  • Is Active - whether rule is active and is processed, when event is triggered.
  • Priority - order which will be used for rules sorting before applying. The lesser - the earlier.
  • Stop Further Rules Processing - If option enabled, other rules, binded to the same event, will not be processed. This option is extremely useful when building complex automation.

Conditions tab

This is the most important tab of the rule - it breaks into Event and Conditions sections, and define - when this rule shall be triggered.

- Event subsection

This section binds the rule to one of events, that are fired on changing RMA Request properties or adding a new message to communication. There's five possible events:

  • New RMA has been created - fired, when RMA created, and its basic properties (including Custom Fields, but excluding return items) are saved.
  • RMA has been changed - fired, whenever any RMA property is changed. Also fired, when RMA is created, and return items are added.
  • New reply from customer - fired, when to RMA history a new message from customer is added.
  • New reply from staff - fired, when to RMA history a new message from staff is added.
  • Check every hour - fired every hour, on crontask execution. If you wish to use this event, make sure, that crontask mirasvit_rma is running. You can do it, for example, via third-party extension AoE Scheduler.

On creation stage RMA two events consequently appear:

  • New RMA has been created - on this stage RMA is issued, and basic properties are filled - such as store and customer, and initial status is set.
  • RMA has been changed - on this stage items are added to the RMA, and filled rest of properties.
    Therefore, if you need to control properties of items, you need to use RMA has been changed event, along with additional condition of Status. Read more at Conditional automatic messages in Statuses.

- Conditions subsection

This section contains conditions, which define, when current rule shall be executed. There are four possible global modes of applying conditions, shown in special header If [APPLY MODE] of these conditions are [VALIDATION MODE]:

Applying modes define, when rule shall be triggered:

  • ALL - implies, that rule will be executed only when strictly all conditions were met;
  • ANY - implies, that rule will be executed only when one or more (but not all) of conditions were met;

Validation modes define, which result can produce each condition to be counted as "met":

  • TRUE - implies. that conditions should be valid.
  • FALSE - implies, that conditions should be invalid.

Blocks can be nested. To insert a block with global mode, you need to select Conditions Combination option as a condition. This allows to create flexible condition sets to satisfy policy of any complexity.

Each block can contain one or more conditions. Here is their list:

  • Last message body - Content of the last public message, left in particular RMA
  • Created at - Date of RMA creation
  • Updated at - Date of RMA last update (e. q. new message appeared, or properties changed)
  • Store - Store, from where RMA was submitted (note: this condition can not detect backend-created RMAs, as they can be binded to any store)
  • Status (before change) - Status, which particular RMA has prior to event firing (used only for RMA has been changed event)
  • Status - Current RMA status
  • Owner (before change) - Owner, which held particular RMA prior to event firing (used only for RMA has been changed event)
  • Owner - Current RMA owner
  • Is Archived (before change) - whether particular RMA was in archive prior to event firing (used only for RMA was changed event)
  • Is Archived - whether RMA is archived
  • Last Reply By - Last replier in this RMA: Customer or Staff agent
  • Hours since Created - Tme period from creation of particular RMA (note: this condition is not precise, use equal or greater or equal or less than comparators here)
  • Hours since Updated - Time period from last update of particular RMA (note: this condition is not precise, use equal or greater or equal or less than comparators here)
  • Hours since Last Reply - Time period from last message appearance in particular RMA (note: this condition is not precise, use equal or greater or equal or less than comparators here)

There's three special conditions, that allows you to analyze conditionals of returned items. They can be applied on any event, except of New RMA has been created.

  • Items have Reason - checks, whether at least one of returned item has certain Reason.
  • Items have Condition - checks, whether at least one of returned item has certain Condition.
  • Items have Resolution - checks, whether at least one of returned item has certain Resolution.

You can also use as conditions RMA-based Custom Fields. There's, however, some differences in their usage.

Each Custom Field comes as two different condition. So, if the field is Repairing service, then it will result in two conditions:

  • Repairing service (before change) - checks value of the field before event was fired.
  • Repairing service - check current value of the field.

It allows you to detect changing values of that fields, and thus - flexibly react to additional information, supplied in your RMA. Read more at Examples of Workflow Rules section below.

Actions tab

This tab defines actions, which should be performed if conditions, defined in Conditions tab are met.

  • Set Status - sets a new Status for the RMA
  • Set Owner - sets a new Owner for the RMA
  • Resolved - allows to mark the RMA as solved or unresolved
  • Archive - allows to mark the RMA as archived or unarchived

Actually, you need to set Action even if Rule is intended just to send custom notification. We recommend using in this case Resolved action.

Notifications tab

If conditions are met, and action is executed, Rule can send notification with details.

  • Send email to RMA owner - If option enabled, current email will be sent to RMA owner
  • Send email to customer - If option enabled, current email will be sent to customer
  • Send email to other email addresses - Allows to send emails to additional addresses (if you need to send more to one address, use comma to separate them).
  • Email subject - Email subject
  • Email body - Message, which should be sent. You need to supply here a sub-template, which will be enclosed in template, defined at Template of Rule Notification option at Settings.
    Since it is a subtemplate, you can use transactional email variables here. Read more at Email Notifications section.
  • Attach files which were attached to the last message - If option enabled, attached to the last message files will be attached to the Rule notification as well.

Examples of Workflow Rules

  • Automatically approve all new RMA requests, which are placed by Staff from backend

    Sometimes staff members place RMA from backend, based by phone call, or other external communication channel. In this case is useful automatically to approve such requests.

    • Event: RMA has been changed
    • Conditions:
      • Status is Pending Approval
      • Last Reply By is Staff
      • Hours since Created equals or less than 1
    • Actions:
      • Set Status: Approved

    Note: Additional check for a hours from creation allows you to select only New RMA, otherwise this rule will be triggered, whenever RMA is answered by Staff.

  • Automatically reject all RMA with Opened condition

    This workflow rule can be used for rejecting all requests for returning already opened merchandize.

    • Event: RMA has been changed
    • Conditions:
      • Status is Pending Approval
      • Items have condition is Opened
    • Actions:
      • Set Status: Rejected
      • Resolved: Mark as resolved

     

  • On approval of RMA Request, assign it to different staff depending of desired Resolution

    If you have more than one staff, managing returns, you may want to automate their assignment. For that you will need a separate Rule for each Resolution type.

    Assume, that you have John Doe staff, responsible for Exchanges, and Jane Doe, responsible for Refund. In this case you will need two different rules:

    Rule for Exchange Staff:

    • Event: RMA has been changed
    • Conditions:
      • Status is Approved
      • Status (before change) is not Approved
      • Items have resolution is Exchange
    • Actions:
      • Set Owner: John Doe

    Rule for Refund Staff:

    • Event: RMA has been changed
    • Conditions:
      • Status is Approved
      • Status (before change) is not Approved
      • Items have resolution is Refund
    • Actions:
      • Set Owner: Jane Doe

    Note: This rule uses so-called transition detection, e. q. using the same property check of value before event, and current value. It ensures, that Rule will be triggered only once, when Status was changed from one status to another.

  • Analyze customer's answer and discard all RMA, when customer uses hate speech or posts spam

    Sometimes, there can be customers, that do not want actually be satisfied. You can detect it, and automatically discard it, with a notification to him.

    • Event: New reply from customer
    • Conditions:
      • If ANY of these conditions are TRUE :
        • Last message body contains bastard
        • Last message body contains freak
        • Last message body contains retarded
        • [ANY OTHER KEYWORD]
    • Actions:
      • Resolved: Mark as resolved
      • Set Status: Closed
      • Archive: Move to Archive
    • Notifications:
      • Send email to customer: Yes
      • Email subject: Your request had been dropped
      • Email body: [Message about inappropriate lexic]

     

  • Send a reminder to a customer, who did not answered to Staff message for 3 days

    Sometimes RMA Requests are forgotten by customers, or staff answers accidentally went to Spam folder. You can send the customers a reminder.

    • Event: Check every hour
    • Conditions:
      • Last Reply By is Staff
      • Hours since Last reply equals or greater than 72 (24 x 3 = 72 hours)
    • Actions:
      • Resolved: Mark as unresolved
    • Notifications:
      • Send email to customer: Yes
      • Email subject: We've just contacted you to remind, that you had placed a return request'
      • Email body: [Message with details]

    Note: Just the same way you can close dead (e. q. unanswered) RMA - by increasing Hours since Last reply value and using Set Status action.

Examples, described above, are merely simple and mostly requested cases. The real possibilities behing Workflow Rules enhancements - are nearly limitless.

RMA