FSM Notification Configuration

Notification configuration controls automatic email requests, named email definitions, senders, recipients, message content, attachments, and the records associated with a sent message.

Service report emails use an HTML template for the message body and a separate XML template for the attached PDF. This topic covers email configuration. See FSM Service Report Configuration for PDF templates, report data, layout, and the Service Report button.

This topic covers:

• Where Notifications Are Configured

• Core Email Definitions

• Automatic Notification Rules

• Email Definition Properties

• Configuring Recipients

• Configuring Email Content

• Configuring Attachments

• Associating Messages with Records

• Language and Translations

• Notification Processing and Duplicate Checks

• Performance Reference

Where Notifications Are Configured

Use the notification object in the configuration file. Configure each record family separately.

Property	Accepted Value	Standard Value	Purpose
caseRules	Array of notification rules.	[]	Selects Case emails to request automatically.
caseEmail	Object containing named email definitions.	Includes servicereport.	Defines Case emails.
taskRules	Array of notification rules.	[]	Selects CRM Task emails to request automatically.
taskEmail	Object containing named email definitions.	Includes servicereport.	Defines CRM Task emails.
projectTaskRules	Array of notification rules.	[]	Selects Project Task emails to request automatically.
projectTaskEmail	Object containing named email definitions.	Includes servicereport.	Defines Project Task emails.
employeeEmail	Object containing named email definitions.	Includes mobilelogin.	Defines Employee emails, including the FSM Mobile login email.
emailSentRange	Integer number of days.	30	Sets the lookback period used to find an already-sent message for the same notification request.

The standard automatic rule arrays are empty. Defining an email does not enable automatic sending. Service Report actions can request an email separately from automatic rules.

There is no corresponding employeeRules property. The standard FSM Mobile login email is requested through the Employee action.

Use FSM Configuration for configuration merging, activation, syntax validation, and Preview.

Standard default JSON for automatic rules and the sent-message lookback (the named email definitions remain inherited):

            {
  "notification": {
    "caseRules": [],
    "taskRules": [],
    "projectTaskRules": [],
    "emailSentRange": 30
  }
} 

          

Core Email Definitions

Case Service Report Email

The following table describes the standard behavior of notification.caseEmail.servicereport.

Setting	Standard Behavior
Author	Employee assigned to the case.
Recipients	Email address on the case.
Email template	templates/casereport.html
Email-body data	Case record under case, and subsidiary record when the Subsidiaries feature is enabled.
Message association	Case and its contact, where supplied.
Attachment	Case service report PDF.

CRM Task Service Report Email

The following table describes the standard behavior of notification.taskEmail.servicereport.

Setting	Standard Behavior
Author	Task assignee.
Recipients	Email address on the linked case. If the task has no linked case, the customer search uses the primary contact's email address, falling back to the customer's email address.
Email template	templates/taskreport.html
Email-body data	Task record under task, and subsidiary record when the Subsidiaries feature is enabled.
Message association	Linked case and the contact found on that case, where supplied.
Attachment	CRM Task service report PDF.

The customer recipient search is used only when there is no linked case. An empty case email address does not itself cause the customer search to be used.

Project Task Service Report Email

The following table describes the standard behavior of notification.projectTaskEmail.servicereport.

Setting	Standard Behavior
Author	First resource returned by the project task assignment search.
Recipients	Primary contact's email address on the linked project.
Email template	templates/projecttaskreport.html
Email-body data	Project Task under projecttask, Project under project, and subsidiary record when the Subsidiaries feature is enabled.
Message association	Linked project.
Attachment	Project Task service report PDF.

The first Project Task resource returned is not necessarily a designated lead resource.

Employee Mobile Login Email

The following table describes the standard behavior of notification.employeeEmail.mobilelogin.

Setting	Standard Behavior
Author	The standard definition supplies no explicit author. The sending process uses the current execution user's ID.
Recipients	Employee's email address.
Email template	templates/mobilelogin.html
Email-body data	Employee under employee, FSM Mobile link under mobile, and subsidiary record when the Subsidiaries feature is enabled.
Message association	Employee.
Attachments	None supplied in the standard definition.

These template references are relative to the FSM script folder in the File Cabinet. For a custom template stored elsewhere, use its full File Cabinet path.

Automatic Notification Rules

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.

For example, "emails": ["servicereport"] in a task rule selects notification.taskEmail.servicereport. It does not 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
caseRules	project: Project type. case: Case type. status: Case status. stage: Case stage.	Case type, status, or stage changes.
taskRules	project: Project type. case: Linked case type. task: Task type. status: Task status.	Task type or status changes.
projectTaskRules	project: Project type. task: Task type. status: Project task status.	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 does not trigger reassessment of every linked work record.

Rule conditions test the resulting values rather than comparing previous and resulting values.

Note:

A completed-status condition does not 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 in Rule Inputs and Evaluation.

FSM uses the first matching rule in the array. Place specific rules before more general rules. Later matching rules do not 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.

Example: Request a Service Report 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 does not change the email's recipients, content, or attachment.

Email Definition Properties

The following table describes properties for each named email, such as notification.taskEmail.servicereport.

Template tags can supply values within email definitions. Their resolved values must have the type and structure accepted by the property. See FSM Expressions and Template Tags for syntax and evaluation details. The notification service renders these definitions, which differ from FSM Mobile element expressions.

Property	Resolved Value	Standard Value or Fallback	Effect
author	Employee internal ID.	Record-specific standard definition. If the resolved author is not supplied or evaluates as false, the send function uses the current execution user's ID.	Sets the sender.
recipients	Recipient address or collection accepted by NetSuite email sending.	Record-specific standard definition. The renderer's empty-array fallback supplies no recipients.	Sets the primary recipients.
cc	Email address or collection of addresses.	Not supplied in the standard definitions.	Sets carbon-copy recipients.
bcc	Email address or collection of addresses.	Not supplied in the standard definitions.	Sets blind-copy recipients.
reply	Email address string.	Not supplied in the standard definitions.	Sets the reply-to address.
subject	String.	If omitted or empty, the rendered email body's <title> supplies the subject, with whitespace normalized.	Sets the message subject.
body	Object containing template and named template data.	Record-specific standard definition.	Defines the HTML message body.
attachments	Collection of files or report definitions that resolves to an attachment array.	Service report PDF for the three service email definitions. No attachment for the FSM Mobile login email.	Attaches files to the message.
records	Object containing message-association properties.	Record-specific standard definition.	Associates the sent message with NetSuite records.
bounce	Boolean.	true when omitted from the resolved definition.	Requests bounceback notifications to the sender.
internal	Boolean.	false in the configuration schema. No explicit value in the standard email definitions.	When true, marks the message as internal so it is not visible in the Customer Center.

internal: true controls Message visibility. It does not prevent email delivery to an external recipient.

A notification needs a valid sender, at least one valid recipient, and permissions for the execution role to send. The author fallback does not select a designated business sender.

Configuring Recipients

Recipient collections can combine fixed addresses, template-tag values, and configured searches.

The standard recipient collections use array: true. For combining named values and searches, see Combining Search Results.

Example: Add an Internal Copy

The following fragment adds a carbon-copy recipient to the CRM Task service report. It retains the standard primary recipient selection.

              {
  "notification": {
    "taskEmail": {
      "servicereport": {
        "cc": {
          "array": true,
          "serviceOffice": "[e-mail]"
        }
      }
    }
  }
} 

            

Replace the example address with the intended address. Review the merged configuration for any existing cc properties: object merging retains those properties too.

Adding a property to the standard recipients object adds recipients without removing the existing case or customer recipient sources. The complete merged collection determines the recipients.

For recipient searches, see FSM Searches and Field Mapping. Use selective filters and return the email addresses required by the notification.

Configuring Email Content

The body.template property selects the HTML FreeMarker template. Other properties within body supply its data.

FreeMarker inserts those values and evaluates template directives to produce the HTML message. A service report PDF uses FreeMarker to produce XML. The Big Faceless Organization (BFO) Report Generator then generates the PDF. See How Service Reports Are Rendered for the rendering stages and public BFO and FreeMarker references.

For searches supplied to body, match template references to the effective objectify setting. Native results use NetSuite search column names, and mapped results use the map's property names. For the setting, see Returning Mapped Values or Native Search Results. For examples of shared template-data behavior, see Field Names in Report Templates.

For additional JSON data that must preserve zero or false values, use a named object. See Adding Data for this rendering limitation and an example. If an email-data search can exceed 1,000 rows, check its retrieval limit as described in Retrieving More Than 1,000 Results.

The following table distinguishes configuration template-tag context from the named data supplied to the HTML template.

Email Family	Configuration Tag Context	HTML Template Data
Case	supportcase	case
CRM Task	task	task
Project Task	projecttask	projecttask and project
Employee	employee	employee and FSM Mobile link as mobile.

For example, the case definition uses the configuration tag ${ supportcase.id } to load a case record under body.case. The HTML template accesses that supplied data as case.

Keep configuration template tags and FreeMarker template syntax distinct. See FSM Expressions and Template Tags for configuration tags and the FreeMarker Manual for template syntax.

Example: Change the CRM Task Email Template and Subject

The following fragment changes the email template and subject and retains inherited task data and the service report PDF.

              {
  "notification": {
    "taskEmail": {
      "servicereport": {
        "subject": "Service report for task ${ task.id }",
        "body": {
          "template": "/SuiteScripts/Customer Templates/task-service-email.html"
        }
      }
    }
  }
} 

            

The example File Cabinet path must refer to an existing file. Copy the standard template before modifying it, and retain the data names used by the replacement template.

Use a complete HTML document with an <html> element. FSM adds a notification identifier to that element so a later duplicate check can find the sent message. If subject is omitted, include a suitable <title> to supply the subject.

To add content, supply it under a named property in body and reference that name in the HTML template. Adding data to body does not automatically add it to the PDF. PDF data is supplied separately under the attachment's contents object. For details, see Supplying Report Data.

Configuring Attachments

The standard service emails define attachments.array: true and a named servicereport report definition. FSM resolves the collection, renders the report, and attaches the resulting PDF.

Additional File Cabinet files can be included by path. For PDF properties, XML templates, filenames, and report data, see Report File Properties.

Example: Add a File to the CRM Task Email

The following fragment adds a file and retains the inherited service report attachment.

              {
  "notification": {
    "taskEmail": {
      "servicereport": {
        "attachments": {
          "array": true,
          "instructions": "/SuiteScripts/Customer Templates/service-instructions.pdf"
        }
      }
    }
  }
} 

            

Use an existing File Cabinet path. Keep the service report PDF first: the record's PDF preview returns the first rendered attachment.

Email and attachment sizes remain subject to the email limits in NetSuite. A successful PDF preview does not establish that the complete email can be sent with all attachments.

Associating Messages with Records

records associates the sent message with NetSuite records. It does not load template data, choose recipients, or attach record files to the email.

Property	Value	Purpose
transaction	Internal ID.	Associates the message with a transaction or opportunity.
activity	Internal ID.	Associates the message with a case or campaign.
entity	Internal ID.	Associates the message with an entity, such as a contact, customer, project, or employee.
recordtype	Custom record type identifier.	Identifies the custom record type. Use with record.
record	Custom record internal ID.	Identifies the custom record instance. Use with recordtype.

Do not assume that setting activity to a CRM task or project task ID provides a task message association. The standard task email associates its message with the linked case and contact. The standard project task email associates its message with the project.

If an association is not required, omit it when creating an email definition. For an inherited association, remove the relevant property using the configuration merge rules.

Language and Translations

When Multi-Language is enabled, service notifications first select the customer's language. If no customer language is available, notifications use the subsidiary's language, followed by the account's default language.

Employee notifications select the employee's language, then the subsidiary's language, then the account's default language.

When Multi-Language is disabled, notifications use the account's default language.

The selected language is used when rendering the email and its report attachments. The presence of a language setting does not translate arbitrary customer-written content. Check any custom template text and translation references in each intended language.

See Language and Translations for report-template considerations.

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. See FSM Script Reference for deployment and execution details.

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 do not 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.

The Sent-Message Lookback Period

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 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 does not establish that the recipient received or read the email.

See FSM Service Reports and Notifications for notification behavior, the Notification Record topic for record fields, and FSM Script Reference for processing and execution information.

Performance Reference

For performance measurement and data capture, see FSM Performance and Data Collection.

Related Topics

• FSM Configuration Reference
• FSM Service Report Configuration
• FSM Configuration
• FSM Searches and Field Mapping
• FSM Expressions and Template Tags
• FSM Service Reports and Notifications
• FSM NetSuite View Configuration
• FSM Script Reference

• FSM Performance and Data Collection

General Notices