happy-technologies-llc/happy-platform-skills/business-rules
Claude Code and agent skill by happy-technologies-llc/happy-platform-skills
- community
Checking that the SKILL.md file is still in the repository.
Develop secure, efficient business rules with correct timing, conditions, Glide API patterns, error handling, and tests.
Install
npx vskill@latest install happy-technologies-llc/happy-platform-skills/business-rulesSKILL.md
Business Rules Development
Overview
Business rules are server-side scripts that execute when records are displayed, inserted, updated, deleted, or queried. They are the backbone of ServiceNow automation.
- What problem does it solve? Automates record-level logic, enforces data integrity, and triggers workflows based on record changes
- Who should use this skill? ServiceNow developers building custom automation logic
- Expected outcomes: Well-structured, performant business rules that follow ServiceNow best practices
Prerequisites
- Roles:
adminor scoped app developer role - Knowledge: JavaScript fundamentals, GlideRecord API basics
- Access: sys_script table, target table for business rule
- Related skills:
admin/script-execution,admin/update-set-management
When to Use Business Rules
Timing Matrix
| When | Trigger | Use Case | current/previous | |
|---|---|---|---|---|
| before | Insert/Update/Delete | Validate data, set field values, abort operations | Both available | |
| after | Insert/Update/Delete | Create related records, send notifications, external integrations | Both available | |
| async | Insert/Update/Delete | Long-running operations, external API calls | Only current | |
| display | Query/Display | Calculate runtime values, populate scratchpad | Only current |
Decision Guide
Use BEFORE when:
- Setting default values based on other fields
- Validating data before save
- Modifying field values before commit
- Aborting invalid operations with
current.setAbortAction(true)
Use AFTER when:
- Creating child/related records
- Sending notifications (after record is committed)
- Updating other tables
- Triggering workflows
Use ASYNC when:
- Making external REST/SOAP calls
- Processing large data sets
- Operations that can fail without blocking the user
- Long-running calculations
Use DISPLAY when:
- Calculating values for form display only
- Populating g_scratchpad for client scripts
- Runtime-only field values (not stored)
Procedure
Phase 1: Create a Business Rule
Step 1.1: Query Table Schema
First, understand the target table structure.
Using MCP:
Step 1.2: Create Basic Business Rule
Using MCP:
Step 1.3: Create After Business Rule
Using MCP:
Step 1.4: Create Async Business Rule
Using MCP:
Phase 2: Using current and previous Objects
Step 2.1: Understanding current vs previous
The current object represents the record being processed. The previous object contains field values before the current transaction.
Key Differences:
| Aspect | current | previous | |
|---|---|---|---|
| Availability | All business rules | before/after only (null in async) | |
| Modifiable | Yes (before rules) | No (read-only) | |
| Insert operations | Has values | null | |
| Values | New/modified | Original before change |
Step 2.2: Detecting Field Changes
Using .changes() Method (Recommended):
Manual Change Detection (When .changes() Not Suitable):
Step 2.3: Checking Operation Type
Phase 3: Condition Field vs Script Conditions
Step 3.1: Condition Field (Preferred for Simple Conditions)
The condition field uses encoded queries and is evaluated BEFORE the script runs. This is more efficient because:
- Evaluated at the database level
- Script never executes if condition fails
- No JavaScript overhead
Best Practices for Condition Field:
Common Condition Operators:
| Operator | Meaning | Example | |
|---|---|---|---|
| CHANGES | Field value changed | stateCHANGES | |
| VALCHANGES | Changed TO specific value | stateVALCHANGES6 | |
| CHANGESFROM | Changed FROM specific value | stateCHANGESFROM1 | |
| = | Equals | priority=1 | |
| != | Not equals | state!=7 | |
| ISEMPTY | Field is empty | assigned_toISEMPTY | |
| ISNOTEMPTY | Field has value | assigned_toISNOTEMPTY |
Step 3.2: Script Conditions (For Complex Logic)
Use script conditions only when the condition field cannot express the logic.
Using MCP:
When to Use Script Conditions:
- Complex date calculations
- Cross-table validations
- Dynamic conditions based on user roles
- Calculations involving multiple fields
- Conditions requiring GlideRecord queries
Phase 4: Common Glide API Methods
Step 4.1: GlideRecord Essentials
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/development/business-rules/SKILL.md
Popularity
- Repository stars
- 29
- Repository forks
- 11
- 7-day trend score
- 17
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/happy-technologies-llc/happy-platform-skills/business-rules)