Call a Script Include from a Business Rule

Business Rules call Script Includes through direct instantiation — new ClassName() creates an instance, then you invoke methods normally. The critical mistake developers make is assuming Script Includes work like libraries — they don't. Each instantiation creates a separate object with its own state, and scope boundaries will block your calls entirely if the Script Include lives in a different application scope than your Business Rule.

When to use this pattern

• Complex business logic that multiple Business Rules need to share
• Calculations or data transformations that require multiple database queries
• Integration calls to external systems triggered by record changes
• Utility functions that need to be unit tested independently of the Business Rule

When NOT to use this pattern

• Simple field validations or calculations that fit in 5-10 lines — keep them inline
• Client-side operations — use GlideAjax to call Script Includes from Client Scripts
• One-off logic that only applies to a single table and Business Rule context
• Performance-critical paths where instantiation overhead matters — inline the code

Key behaviors and gotchas

• Script Include class name must exactly match the Name field — case sensitive, no typos
• Global Script Includes are accessible from scoped apps, but scoped Script Includes are not accessible from global scope
• Pass the current GlideRecord directly — the Script Include can access all field values and methods
• Each instantiation creates a new object — instance variables don't persist across Business Rule executions
• Script Include methods inherit the same security context as the Business Rule — no additional ACL checks
• Exceptions thrown in Script Include methods will abort the Business Rule transaction unless caught