Business Rule Extension Framework

Business Rules that reach every corner of the form.

Extend native Business Rules to control tabs, sections, multi-selects, subgrids, and timelines without writing per-entity JavaScript.

What it unlocks

One global framework that lets Business Rules control the form UI everywhere.

Tabs + sections

Hide or show any tab or section across main forms.

Multi-select control

Hide, show, lock, or require multi-select choices.

Subgrids + timeline

Hide or show subgrids and timelines.

Global reach

One managed solution runs on every main form.

Download the solution

How to use it

Build, target, and enforce the rule

Follow the setup steps, craft the command string, and keep rules predictable with best practices.

Create the Business Rule

Import BusinessRuleExtensions_v1_Managed.zip and publish all customizations before you start.

1

Create the trigger field

Add a single line text column whose logical name ends in brextension (ex: new_brextension).

Recommended length: 100-200 chars. Add a description to capture its purpose for later.
2

Add to the form (hidden)

Place the field on the main form and hide it.

The framework will not run unless the field exists on the form body.
3

Build the business rule

Use Set Field Value to write the command stringHIDE:FLD:new_multiselectoptions into the brextension field.

Add explicit ELSE logic to undo actions.
Business Rule Extension Framework

Command Studio

Build command strings that let standard Business Rules hide or show tabs, sections, subgrids, and timelines, plus lock or require multi-select fields.

Command syntax
ACTION:TYPE:LOGICAL_NAME
Multiple commands are comma-separated.

Actions

  • HIDEMake the element invisible.
  • SHOWBring the element into view.
  • LOCKForce read-only on a field.
  • UNLOCKReturn a field to editable.
  • REQBusiness required (red asterisk).
  • OPTRemove business required state.

Targets

  • FLDFields, subgrids, timelines.
  • TABForm tabs (name, not label).
  • SECSections (name, not label).

Examples

HIDE:FLD:new_multiselectoptionsLOCK:FLD:emailaddress1HIDE:TAB:tab_detailsHIDE:SEC:general_section_1HIDE:TAB:tab_3, SHOW:FLD:mobilephone, REQ:FLD:mobilephone

Builder

Choose an action, select the target type, then type the logical name or control name.

Current commandHIDE:FLD:your_name_here

Best practices

Keep rules explicit and predictable so multiple admins can maintain them.

Split rules by purpose

Create separate brextension fields for visibility, locking, and required logic so each rule edits only its own scope.

Explicit ELSE

Always set the opposite action in the ELSE branch; clearing the field does nothing by itself.

Conflicts resolve by last update

If two fields fight for control, the last update wins (often alphabetical on load).

Quick Create formsRequires manual library hookup

Quick Create forms need a manual library hookup because the global ribbon does not load reliably.

  1. Add the brextension field to the Quick Create form body.
  2. Form properties → add asgerj_BRExtender.js, OnLoad: BRExtension.init (pass execution context).
  3. Set Business Rule scope to Entity (or All Forms).
How it worksArchitecture details

The framework uses a global injection pattern to listen for commands on every main form.

Global ribbon injection

An invisible global command bar button initializes the script on every entity, even read-only records.

Proxy trigger fields

The script searches for text fields ending in brextension and monitors them.

Heartbeat monitor

Every second, it checks for changes and executes new commands immediately.

Zero idle impact

If no trigger field exists on the form, it exits instantly.

Troubleshooting checklistCommon setup misses

If commands do not fire, verify the fundamentals before debugging.

  • Use the logical name (tab_3), not the label (Summary).
  • Confirm the brextension field is on the form body.
  • Activate the Business Rule and scope it to Entity or All Forms.
  • No spaces inside keywords: HIDE:TAB is correct; HIDE : TAB is not.