AWE can help automate a whole lot of things for you. And the visualization of what's possible can be somewhat difficult. So here are some more detailed examples for each kind of Rule and Action. First, the basics: you have a clear idea of two things: 

  • What you want to happen 
  • When you want it to happen.

The What is the Rule and the When is an Action. Let's look at the Rule - the What - first. You can make this quite complex, depending on your business needs. For example, you may want to send an email only if the invoice value is over $ 1000 (not being nice to the small customers, eh?). Or, you want to send the email only the first time an invoice is set up for a given customer. And the second time onwards, maybe you'll send them a case of beer instead - yes, we can automate that too, if your vendor has a Web Service that we can hit as a URL. 

  1. The Rule itself has three aspects to it:
  2. The Event - whether data was added, updated or either. 
  3. The Condition - details like "when an invoice is added, but the invoice is at least $ 100 in value" or "when a contact is added, but only if s/he has agreed to be contacted". 
  4. The Timing - this can be one of three things: 
    • as a Trigger - meaning, as soon as the Event occurs; this is typical - say, send email immediately when an Invoice is created 
    • as an Escalation - meaning, some minutes before of after a date that was set up when the Event occurred; for example, 15 minutes before a meeting's Start time or 2 hours after a Ticket was created 
    • as an Automation - meaning, at a specific time every day/day of week/day of month; for example, every day at 8 PM, for all the invoices created in the last 24 hours.

    Actions, tied to each Rule, can be one of the following things:

    • Assign a record based on a round-robin calculation. The "calculation" here generates a list of what we call "candidate values", i.e. the list of values from which the AWE will pick one to assign, can be based on complex conditions on existing data. For example, you could automatically assign a new Contact to a specific Agent in a call center based on the language of that Contact, his/her PIN Code and the time-of-day s/he called at. The Agents that qualify to be assigned a specific Contact in this case could come from a list generated based on the Agents’ own language skills. And every time AWE assigns an agent, it remembers the last one it assigned and the sequence it assigned it in, so it can assign the "next" one the next time. Of course, next time around, if the "next" agent is not in the "candidate" list (say, s/he's off work that day), AWE picks the one after, and so on.
    • Create an Event or Task for a specific User when data that is added or updated satisfies a specific condition. For example, you could set up a rule that a Task be created for an Accounts user to validate a new Customer every time an order of greater than $ 2,000 is received.
    • Email a response to a user or a contact using a pre-defined email format; the format can be complex, since it can include any data from the record that was added/updated and some related Objects.
    • Hit a URL configured, with specific parameters; best used to integrate with external systems, this is the mechanism to use when you want to leverage Push Notifications in Impel, too (say, to light up a badge on a user's Lead tab when a Lead is assigned to him/her).
    • Insert a record into a related Object, possibly to cause other AWE effects and to keep reporting in line. For example, you may have an outbound calling operation where agents talk to prospects and, when someone responds positively, you want to agent to just check a box; that in turn could insert a Lead or an Opportunity for a specific salesperson to follow up on.
    • Roll up a value from a set of records into a summary record. This is mostly for reporting needs, where you want efficient reporting on, say, the total value of invoices over $ 2000 on each Account that you track.
    • Send a text message to a user or a contact, much like sending an email. More personal but more intrusive (only in some countries!), this can be a pre-formatted message that includes things like a Customer Number or a Ticket Number.
    • Update a Counter of a specific format, where the format can be very complex. For example, you may want an Invoice Number at a Branch level in a multi-branch business, where each branch carries its own sequence number of invoices but all branches use the same format of the Invoice Number. Say the format is INV--. The part of the Invoice Number of all invoices in a given branch needs to be in sequence, but invoices in difference branches must be in different sequences. We hope that makes sense...
    • Update a column, either on the record that was just added/updated or on a record in a related Object. For example, when Impel's Email-to-Ticket brings in a new Ticket from a customer, you may want to assign it to an agent based on the customer's Account or some other factor. That's a great case for an AWE Update Action.

    For a given Rule, you can set up multiple Actions, of course. And you can set them up to kick in in a specific sequence, so that the effects of one Action are available to the next one for the same Rule. So you could dot he following, as one rule and six Actions:

    • Every time a large-value invoice is added
      • send an email to the customer
      • then send a text message to the customer
      • then set up a new Activity for someone from Admin to run a credit-report on the customer
      • then set up a follow-up Activity for a call-center agent to call the customer the next morning for a Welcome conversation
      • then set up a Push Notification for the call-center Agent, to kick in 5 minutes before the Welcome call is to be made
      • then hit an external URL to tell a different system the details of this new invoice.
    You could also set up multiple Rules to kick in, in a specific sequence, for the same event. For example, an Impel customer that sells online Tests (among other things) has  Rules and Actions that work together in this manner:

    • When a call-center agent talks to a prospect and the prospect expresses an interest
      • The agent checks a box on screen that says "Interested"
      • A Front-End Rule (written in JavaScript - more details here) kicks off an update to the most recent Opportunity for that Contact
      • The update kicks off a series of Rules and Actions that do the following:
        • Update Custom Fields on the Opportunity with the prospect's email ID (as user ID to the online Test system) and a randomly-generated string (as password)
        • Hit a URL in the online Test system, submitting the prospect's user ID and password (among other details), to create a profile record
        • Send an email to the prospect, with details and a link to the online Test system and the user's user ID and password
        • Send a text message to the prospect, with a more abbreviated set of details
        • Move the Opportunity's Stage to a specific value.
    All in a few hours of work. Seriously.


    Note that AWE Rules don't work in a "cascade" mode, i.e. if one Action updates a record in an Object and there's a different Rule on that Object, the second Rule will not kick in. If it did, it could lead to what computer-science people call a "race condition". And we don't want that, do we?


    Rules and Actions can be set up by people who have a good sense for the Impel data model and some programming skills. The user-interface sucks, so we don't normally have our customers work on this kind of stuff. We have Partners who'll help do this - in a matter of hours.