Configuring FSM Notification Rules and Processing
Each rule is an object containing conditions and an emails array. The array names the email definitions to request from the matching record family's email object.
This topic includes the following sections:
For example, "emails": ["servicereport"] in a task rule selects notification.taskEmail.servicereport. It doesn't select the case or project task definition with the same name.
Rule Inputs and Evaluation
The following table lists condition properties and changes that trigger evaluation through each record's notification component.
|
Rule Family |
Condition Properties |
Evaluation Triggers |
|---|---|---|
|
|
|
Case type, status, or stage changes. |
|
|
|
Task type or status changes. |
|
|
|
Task type or status changes. |
Type conditions use internal IDs. Status and stage conditions use the values stored by NetSuite, rather than translated display labels.
FSM assesses rules during supported create, copy, edit, and inline-edit record submissions. Assessment occurs when a monitored field differs from its previous value. Evaluation uses the submitted monitored values together with the related-record type context. A change to a related project or case alone doesn't trigger reassessment of every linked work record.
Rule conditions test the resulting values rather than comparing previous and resulting values.
A completed-status condition doesn't limit an email to a single request. For example, changing the task type on an already completed task can cause another rule assessment and another request if the resulting values still match.
Matching Conditions
For condition values and all-condition matching, see Shared Rule Matching. Use only the inputs listed for the applicable notification family. For the input lists, see Rule Inputs and Evaluation.
FSM uses the first matching rule in the array. Place specific rules before more general rules. Later matching rules don't add their emails to the first rule's list.
An empty emails array requests no emails. If such a rule matches first, later rules are not used.
Every email name must exist in the corresponding email definitions. An unknown name causes notification processing to fail when FSM attempts to render that email.
Requesting a Service Report Email for a Completed CRM Task
The following configuration fragment requests the Task service report when a rule assessment finds a Task with an FSM Task type and status COMPLETE.
{
"notification": {
"taskRules": [
{
"task": true,
"status": "COMPLETE",
"emails": ["servicereport"]
}
]
}
}
Merge the fragment into the account configuration. The task: true condition requires a populated task type without restricting the rule to a particular type.
This example replaces the complete taskRules array. Retain any other rules that must continue to apply, in the intended order. It doesn't change the email's recipients, content, or attachment.
Notification Processing and Duplicate Checks
Automatic rules and manual actions create notification requests. Scheduled notification processing turns pending requests into notification records and renders the selected email definition. The process then sends the message and links the resulting message to the notification record.
The notification scheduled deployment is customdeploy_nx_notification. For information about deployment and execution details, see FSM Script Reference.
The Event Pending Notifications field is custevent_nx_notification_pending, and the Employee equivalent is custentity_nx_notification_pending. These fields contain pending requests and don't indicate that a script is currently running.
A pending field can be cleared after its requests have corresponding notification records, before those emails have been sent. An empty pending field is therefore not proof of successful sending.
Lookback Period for Sent Messages
Before sending a notification request, FSM searches for a recent message carrying that request's notification identifier. If it finds one, it links that message rather than sending the same request again.
notification.emailSentRange sets the search lookback period in days. The standard value is 30.
This property is not a send delay, a message-retention period, or a rule that permits only one email message per service record. Separate requests can carry different identifiers and result in separate emails, even within the lookback period.
A linked message provides evidence of the send operation. It doesn't establish that the recipient received or read the email.
For information about notification behavior, see FSM Service Reports and Notifications. For record fields, see FSM Notification Record. For information about processing and execution, see FSM Script Reference.