Smart Event Examples
- Create a new class dimension when a customer is created
- Use a custom field to track new business on a sales order
- Use a custom field to indicate that a customer is no longer new on a sales order
- Add sales rep to the invoice header using a standard field
- Add sales rep to the invoice header using an employee dimension
- Link class to project when it is created automatically by the task
- Send email when a customer is added
- Send email when a class is added or edited
- Send email when a journal entry is made on a designated account
- Send email when a project is created or updated
- Send email when a high priority bill is entered
- Execute an HTTP Post when a customer is added that includes a session ID and API endpoint URL
The following examples give you an idea of what you can accomplish using Smart Events.
Most of the examples include conditions that are used to guide the outcomes. It’s helpful to understand that a condition has a different purpose depending on whether it is used in a Smart Event or a Smart Rule:
- With a Smart Event, a condition is a gating factor. If it evaluates to true, the action of the event can proceed.
- With a Smart Rule, a condition is a data-validation rule that should not be broken. If it evaluates to false (broken) an error or warning is emitted.
If you are new to Smart Events and Smart Rules, take a look at the Smart Event Walkthrough before proceeding. Keep the cheat sheet handy, too.
Create a new class dimension when a customer is created
In this example, a class dimension is created based on the customer ID and customer name when a customer is created.
Object: Customer
Action: API
Events: Add, Set
Condition
1 == 1
API Body
<create_class>
<classid>{!CUSTOMER.CUSTOMERID!}</classid>
<name>{!CUSTOMER.NAME!}</name>
</create_class>
Use a custom field to track new business on a sales order
This example uses the API to select a New Business custom field checkbox on a sales order transaction document for a new customer (less than six months old). The example assumes there is a Start Date custom field on the customer record.
Object: Order Entry Transaction
Document Type: Sales Order
Action: API
Events: Add, Set
Condition
The condition evaluates to true if the customer’s start date was within the last six months.
{!SODOCUMENT.CUSTOMER.START_DATE!} > pastdate(6,"month")
API Body
<update_sotransaction key="{!SODOCUMENT.DOCID!}" disablevalidation="true">
<customfields>
<customfield>
<customfieldname>NEW_BUSINESS</customfieldname>
<customfieldvalue>true</customfieldvalue>
</customfield>
</customfields>
</update_sotransaction>
Use a custom field to indicate that a customer is no longer new on a sales order
This example uses the API to deselect a New Customer custom field checkbox on the customer record when that customer has been engaged for more than six months. The example assumes there is a Start Date custom field on the customer record.
Object: Order Entry Transaction
Document Type: Sales Order
Action: API
Events: Add, Set
Condition
The condition evaluates to true if the customer’s start date was more than six months ago.
{!SODOCUMENT.CUSTOMER.START_DATE!} < pastdate(6,"month")
API Body
<update_customer customerid="{!SODOCUMENT.CUSTOMER.CUSTOMERID!}">
<customfields>
<customfield>
<customfieldname>NEW_CUSTOMER</customfieldname>
<customfieldvalue>false</customfieldvalue>
</customfield>
</customfields>
</update_customer>
Add sales rep to the invoice header using a standard field
The example adds a customer sales rep’s print as field to the sales invoice header, so it can be printed on a custom invoice template. The example gets the sales rep from the related CUSTREP object on the customer record. The example assumes there is a SALES_REP custom field on the header level of Order Entry transactions.
Object Order Entry Transaction
Document Type: Sales Invoice
Action: API
Events: Add
Condition
The condition evaluates to true if the customer sales rep’s print as is not empty.
{!SODOCUMENT.CUSTOMER.CUSTREP.CONTACT.PRINTAS!} != ''
API Body
<update_sotransaction key="{!SODOCUMENT.DOCID!}" disablevalidation="true">
<customfields>
<customfield>
<customfieldname>SALES_REP</customfieldname>
<customfieldvalue>{!SODOCUMENT.CUSTOMER.CUSTREP.CONTACT.PRINTAS!}</customfieldvalue>
</customfield>
</customfields>
</update_sotransaction>
Add sales rep to the invoice header using an employee dimension
The example adds an employee’s print as field to the sales invoice header, so it can be printed on a custom invoice template. The example gets the sales rep from the related employee object on the first line of the entries. The example assumes there is a SALES_REP custom field on the header level of Order Entry transactions.
Object Order Entry Transaction Line
Document Type: Sales Invoice
Action: API
Events: Add
Condition
The condition evaluates to true if the first line item on the invoice has an EMPLOYEENAME value that differs from the SALES_REP value on the invoice itself.
{!SODOCUMENTENTRY.LINE_NO!} == 0 && "{!SODOCUMENTENTRY.EMPLOYEENAME!}" != "{!SODOCUMENTENTRY.SODOCUMENT.SALES_REP!}"
API Body
<update_sotransaction key="{!SODOCUMENTENTRY.DOCHDRID!}" disablevalidation="true">
<customfields>
<customfield>
<customfieldname>SALES_REP</customfieldname>
<customfieldvalue>{!SODOCUMENTENTRY.EMPLOYEE.CONTACT.PRINTAS!}</customfieldvalue>
</customfield>
</customfields>
</update_sotransaction>
Link class to project when it is created automatically by the task
This example uses the API to link a class to a task’s project, when the class is automatically created by the task. This is a setting enabled in the Projects configuration. The example assumes a Many Projects to One Class dimension relationship has been created already and the Project lookup field’s integration name on the Class object is RPROJECT.
Object Task
Action: API
Events: Add
Condition
{!TASK.PROJECTID!} != '' && {!TASK.CLASSID!} != ''
API Body
<update_class key="{!TASK.CLASSID!}">
<customfields>
<customfield>
<customfieldname>RPROJECT</customfieldname>
<customfieldvalue>{!TASK.PROJECT.RECORDNO!}</customfieldvalue>
</customfield>
</customfields>
</update_class>
Send email when a customer is added
This example helps track customer creation by sending email when a customer is added.
Object: Customer
Action: Email
Events: Add
Email Subject
{!COMPANY.TITLE!} | customer {!CUSTOMER.CUSTOMERID!} has been created
Email Body
For company {!COMPANY.TITLE!} a customer {!CUSTOMER.CUSTOMERID!}--{!CUSTOMER.NAME!} has been created/edited
by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}`
Send email when a class is added or edited
This example helps track class creation by sending email when a class is added or edited.
Object: Class
Action: Email
Events: Add, Set
Email Subject
{!COMPANY.TITLE!} | customer {!CLASS.CLASSID!} has been created/edited
Email Body
For company {!COMPANY.TITLE!} a class {!CLASS.CLASSID!}--{!CLASS.NAME!} has been created/edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}
Send email when a journal entry is made on a designated account
This example sends email when a journal entry is added or modified for a given account.
Object GL Entry (AKA Journal Entry Line)
Action: Email
Events: Add, Set
Condition
{!GLDETAIL.ACCOUNTNO!} == 1205
Email Subject
{!COMPANY.TITLE!} | Inter Entity Receivable Entry in Journal {!GLENTRY.BATCHNO!}
Email Body
The Inter Entity Receivable Account was entered in Journal Entry Number {!GLENTRY.BATCHNO!}.
Details:
Transaction Date: {!GLENTRY.EXCH_RATE_DATE!}
Line Number: {!GLENTRY.LINE_NO!}
Account Number: {!GLDETAIL.ACCOUNTNO!}--{!GLDETAIL.ACCOUNTTITLE!}
Transaction Amount: {!GLENTRY.CURRENCY!} {!GLENTRY.TRX_AMOUNT!}
Location Dimension: {!GLENTRY.LOCATION!} -- {!GLENTRY.LOCATIONNAME!}
Date Created: {!GLENTRY.WHENCREATED!}
Send email when a project is created or updated
This example sends email when a project is created or edited.
Object: Project
Action: Email
Events: Add, Set
Email Subject
Project {!PROJECT.PROJECTID!} has been created or edited
Email Body
Note that CURRENTUSER is the user that performed the action that caused the Smart Event to execute.
Project {!PROJECT.PROJECTID!} in company {!COMPANY.TITLE!} was created/edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}.
Send email when a high priority bill is entered
This example sends email when a a high priority bill is entered. The example assumes there is a HIGH_PRIORITY custom field on the header level of AP Bill.
Object: AP Bill
Action: Email
Events: Add, Set
Condition
{!APBILL.HIGH_PRIORITY!} == "True"
Email Subject
{!COMPANY.TITLE!} | Bill Number {!APBILL.RECORDID!} has been created/edited
Email Body
A bill marked as high priority has been entered or edited by {!CURRENTUSER.LOGINID!} -- {!CURRENTUSER.DESCRIPTION!}.
Bill detail:
Bill number: {!APBILL.RECORDID!}
Vendor Name: {!APBILL.VENDORNAME!}
Due date: {!APBILL.WHENDUE!}
Total amount: {!APBILL.TOTALENTERED!}
Total paid: {!APBILL.TOTALPAID!}
Total due: {!APBILL.TOTALDUE!}
Bill URL: {!APBILL.RECORD_URL!}
Execute an HTTP Post when a customer is added that includes a session ID and API endpoint URL
You should use the API_ENDPOINT injection parameter in any component that includes a SESSIONID. Your server-side code should then use the endpoint when calling back to Sage Intacct Web Services (instead of using one hard-coded to https://api.intacct.com/ia/xml/xmlgw.phtml).
Object: Customer
Action: HTTP Post
Events: Add
Condition
1 == 1
URL: https://www.example.com/customer_sync.php
Method: POST
Arguments
sessionId={!USERPROFILE.SESSIONID!}
endpoint={!API_ENDPOINT!}
customerId={!CUSTOMER.CUSTOMERID!}
Warning: Components are copied to sandbox or Preview environments when you opt in to them. If your code automatically uses the session and new endpoint value, take steps to validate the company ID that makes such a request. Doing so will help you avoid mixing data across these environments.
More information
See the Sage Intacct product help for more information about:
- Methods available for Smart Events and Smart Rules
- Injection parameters