Understanding Script Scope and Execution Context
Global scripts are registered in the Global Scripts form and execute in the context of every form that loads in the SyteLine client. They receive events from all forms and can inspect the active form's name, IDO, and properties to decide whether to act. Form scripts are attached to a specific form definition and only execute when that form is open.
The execution context differs significantly: global scripts see cross-form events and can coordinate between multiple open forms, while form scripts have direct access to their form's components, controls, and layout.
- Global scripts fire for every form: use ThisForm.Name or ThisForm.PrimaryIDOCollection.IDOName to filter
- Form scripts only fire for their specific form: no conditional checks needed for form identity
- Global scripts share a single execution context; variables persist across form switches within a session
- Form scripts get a fresh context each time the form opens; no state bleeds between instances
- Global scripts are defined in System > Global Scripts; form scripts are attached via Form Designer
When to Use Global Scripts
Global scripts are the right choice for cross-cutting concerns that apply to many forms uniformly. Enterprise audit logging, universal field formatting rules, company-wide default value injection, and cross-form data synchronization are ideal global script candidates. For example, a global script that logs every save operation across all forms to a custom audit table provides centralized compliance without modifying hundreds of individual forms.
Similarly, a global script that enforces date format consistency or required field highlighting across the entire application reduces form-by-form maintenance.
- Enterprise audit: log every StdObjectSaved event with form name, user, timestamp to an audit IDO
- Universal formatting: apply consistent date/number display formatting rules across all forms
- Cross-form sync: when a customer is updated in one form, refresh the customer data in all open forms
- Security enforcement: globally disable edit on specific fields based on user group membership
- Session-wide notifications: display maintenance alerts or system messages regardless of active form
When to Use Form Scripts
Form scripts are the correct choice for behavior specific to a single form's workflow. Custom field validation that applies only to the Sales Order form, computed fields unique to the Job Entry form, or control visibility rules for the Purchase Order form should all be form scripts. Form scripts are easier to test in isolation, have no risk of affecting unrelated forms, and can be exported/imported with the form definition during environment promotions.
They also perform better since they only execute when their target form is active, avoiding the overhead of global script filtering logic.
- Form-specific validation: CO Order form validates credit hold status before allowing line item entry
- Unique computed fields: Job Entry calculates estimated completion date based on routing hours and capacity
- Control-specific behavior: PO form hides the Approval section for users below manager level
- Form workflow: Item Master form enforces a step-by-step data entry wizard using tab visibility scripts
- Isolated testing: form scripts can be tested by opening only the target form without side effects
Try it here, free
SyteLine Reorder Point and Safety Stock Calculator
Work out statistically sound safety stock and reorder point values for SyteLine items from demand variability, lead time and service level.
Let Netray AI agents analyze your SyteLine script landscape and recommend the optimal scope for each customization. Reduce script maintenance overhead and improve application performance.