A Business Rule is a server-side script that extends Elaine with project-specific processing logic. Use one when a requirement cannot be expressed with standard configuration alone—for example, to modify a message during rendering, validate content before approval, react to an event, process an import row, or call a connected service.
Business Rules are technical extensions. They are different from audience filters, visual branches in a campaign, and the business policies that an organization documents outside Elaine.
Execution context and rule types
Every Business Rule is assigned a type. The type defines three boundaries:
- which Elaine event or action can invoke the rule;
- which context variables and object data are available to the script; and
- which Elaine Script API functions the rule may call.
For example, a message-analysis rule can inspect message source before approval or campaign start. A link-action rule runs in the context of a clicked link. A message-rendering rule can work with the current content and recipient context while Elaine renders a message. Choosing the wrong type therefore cannot be corrected simply by changing the script: the required event or data may not exist in that context.
Common Business Rule contexts
| Context | Typical purpose | Important consideration |
|---|---|---|
| Message rendering | Prepare or modify content while Elaine personalizes a message. | The rule may run once for every rendered recipient message. |
| Message analysis | Inspect message source and report or set an analysis result before release. | Keep validation results understandable for editors. |
| Link or recipient action | React to a click or another supported recipient event. | Repeated or duplicate events must not cause unintended side effects. |
| Campaign automation or event action | Enrich data, call a service, or perform project-specific processing in an automation. | Define timeouts, errors, and the next campaign state explicitly. |
| Import processing | Prepare an import file, process individual rows, or perform post-processing. | One slow row-level rule can affect the duration of a large import. |
| Workflow or monitoring | React to supported bulk-mail events or monitor a customer-specific process. | Document the operational owner and alerting behavior. |
Example: enrich a message during rendering
Assume a message needs a value that is not stored directly in an Elaine data field. A message-rendering Business Rule can receive the current rendering context, request or calculate the value, and return it for use in the message. The implementation must define what Elaine renders when the value is missing, the external service is unavailable, or the response arrives too late.
Implementation workflow
- Describe the required result and confirm that standard Elaine configuration does not already provide it.
- Select the Business Rule type whose trigger, variables, and Script API access match the use case.
- Document inputs, output or return value, side effects, external dependencies, failure behavior, and owner.
- Implement deterministic, bounded logic and avoid logging secrets or unnecessary personal data.
- Test normal, missing, malformed, duplicate, timeout, and retry cases in a non-production context.
- Version and review the rule, then monitor execution time and errors after activation.
Note
Available Business Rule types, variables, and Script API functions depend on the Elaine release and project configuration. Existing customers can find the type-specific variables and functions in the authenticated customer documentation.