← Back to Blog
TutorialReading time: 12 minutes

11 Artifact Types You Can Generate with AI

A deep dive into every ServiceNow artifact type that snowcoder can generate, from business rules to transform maps.

Introduction

ServiceNow development involves dozens of artifact types, each with its own conventions, best practices, and gotchas. Writing them from scratch is time-consuming and error-prone. With snowcoder, you can generate production-ready artifacts in seconds by simply describing what you need in plain English.

This guide walks through all 11 artifact types that snowcoder supports today. For each one, you'll learn what it is, when to use it, how to prompt snowcoder effectively, and what a generated artifact includes out of the box.

Tip: You can ask snowcoder for any of these artifact types by name. For example, "Generate a Business Rule that..." or "Create a Scheduled Job to..." and snowcoder will produce the right artifact format automatically.

Overview Table

Here is a quick reference for all 11 artifact types, their execution context, relative complexity, and the most common use case for each.

#TypeCategoryComplexityCommon Use Case
1Business RulesServerMediumAuto-populate fields on insert or update
2Client ScriptsClientMediumValidate form data before submission
3Script IncludesServerHighReusable utility classes shared across scripts
4UI PoliciesClientLowShow, hide, or make fields mandatory dynamically
5UI ActionsBothMediumAdd custom buttons to forms or lists
6Scheduled JobsServerMediumNightly cleanup or data synchronization
7Fix ScriptsServerLowOne-time data migration or correction
8ACL RulesServerHighRestrict record or field access by role
9Transform MapsServerHighImport and map CSV or Excel data to tables
10Catalog Client ScriptsClientMediumDynamic behavior on service catalog forms
11Flow Designer ActionsServerHighCustom reusable steps for Flow Designer

1. Business Rules

Business Rules are server-side scripts that execute when a record is displayed, inserted, updated, deleted, or queried. They are the backbone of ServiceNow server logic and the most commonly generated artifact type on the platform.

When to Use

  • Auto-populating or validating field values before a record is saved
  • Enforcing data integrity rules that must run regardless of client
  • Triggering downstream actions (notifications, record creation) after changes
  • Preventing unauthorized operations with abort logic

Example Prompt

"Create a BEFORE INSERT business rule on the Incident table that auto-assigns the assignment group based on the category field. If the category is 'Network', set the group to 'Network Support'. If 'Hardware', set it to 'Hardware Team'. Log a warning if the category doesn't match any mapping."

What snowcoder Generates

  • Correct timing (before/after/async) based on your requirements
  • Proper use of current and previous objects
  • Condition field filtering so the rule only fires when relevant
  • Error handling with gs.addErrorMessage() and abort patterns
  • System logging via gs.warn() or gs.info()
  • Comments explaining each logical block

2. Client Scripts

Client Scripts run in the user's browser and respond to form-level events. ServiceNow supports four client script types: onChange (fires when a field value changes), onLoad (fires when the form loads), onSubmit (fires when the user submits the form), and onCellEdit (fires during list editing).

When to Use

  • Real-time field validation before the user submits
  • Dynamic form behavior such as auto-filling related fields
  • Showing confirmation dialogs when critical fields change
  • Controlling field visibility or values based on user input

Example Prompt

"Create an onChange client script on the Incident form for the 'priority' field. When priority is set to 1 (Critical), make the 'assigned_to' field mandatory and show an info message saying 'Critical incidents require an immediate assignee.' When priority changes away from 1, remove the mandatory requirement."

What snowcoder Generates

  • The correct event type function signature (onChange, onLoad, onSubmit, or onCellEdit)
  • Proper use of g_form API methods for field manipulation
  • Async GlideAjax calls when server data is needed (never synchronous)
  • Guard clauses to handle the initial form load (isLoading check)
  • User-friendly messages via g_form.addInfoMessage() or g_form.addErrorMessage()
  • Clean teardown logic when conditions no longer apply

3. Script Includes

Script Includes are reusable server-side JavaScript classes that can be called from Business Rules, Scheduled Jobs, Fix Scripts, and other server scripts. When marked as "Client callable," they can also be invoked from Client Scripts via GlideAjax. They are the foundation of modular ServiceNow development.

When to Use

  • Encapsulating logic that multiple scripts need to share
  • Building utility libraries for common operations (date handling, string formatting)
  • Creating GlideAjax endpoints so client scripts can call server logic
  • Abstracting integration logic into testable, maintainable classes

Example Prompt

"Create a Script Include called 'IncidentUtils' that provides three methods: (1) getEscalationGroup(category) returns the correct assignment group sys_id for a given category, (2) isBreachingSLA(incidentSysId) returns true if the incident has breached any SLA, and (3) calculateBusinessDays(startDate, endDate) returns the number of business days between two dates. Make it client-callable for the escalation method."

What snowcoder Generates

  • Proper class structure extending AbstractAjaxProcessor when client-callable
  • JSDoc comments for every public method
  • Input validation and null-safety checks
  • GlideAjax response handling with getXMLAnswer()
  • Proper prototype pattern with initialize method
  • Error handling that returns meaningful messages to callers

4. UI Policies

UI Policies control dynamic form behavior without requiring you to write any scripting at all. They let you show or hide fields, make fields mandatory or read-only, and set field values based on conditions. For more advanced logic, UI Policies also support optional "Run script" blocks.

When to Use

  • Showing or hiding form sections based on a field value
  • Making fields mandatory only under certain conditions
  • Setting fields to read-only after a record reaches a specific state
  • Simplifying forms for end users by hiding irrelevant fields

Example Prompt

"Create a UI Policy on the Change Request form. When the type is 'Emergency', make the 'justification' and 'backout_plan' fields mandatory and visible. When the type is 'Standard', hide the 'justification' field and make 'backout_plan' read-only."

What snowcoder Generates

  • Complete UI Policy configuration with conditions and actions
  • Separate "true" and "false" action blocks for toggling behavior
  • Reverse conditions to ensure fields reset when criteria no longer apply
  • Optional script blocks when the logic exceeds simple condition matching
  • Guidance on execution order if multiple UI Policies target the same form

5. UI Actions

UI Actions add custom buttons, links, and context menu items to forms and lists. They can execute client-side scripts, server-side scripts, or both. UI Actions are how you add "Approve" buttons, "Escalate" links, and other custom interactions to the ServiceNow interface.

When to Use

  • Adding custom action buttons to record forms (Approve, Reject, Escalate)
  • Creating list-level bulk operations
  • Adding right-click context menu options
  • Triggering workflows or server logic from the UI with a single click

Example Prompt

"Create a UI Action button called 'Escalate to Manager' on the Incident form. It should only appear when the incident state is 'In Progress' and the current user is in the 'itil' role. When clicked, set the assignment group to the caller's manager's group, add a work note explaining the escalation, and transition the state to 'On Hold'."

What snowcoder Generates

  • Correct placement configuration (form button, list button, or context menu)
  • Condition logic to control when the action is visible
  • Client-side confirmation dialog before executing destructive actions
  • Server-side script for the actual data operation
  • Role-based visibility using the Condition field
  • Proper form submission handling with gsftSubmit() when needed

6. Scheduled Jobs

Scheduled Jobs (also called Scheduled Script Executions) run server-side scripts on a recurring schedule. They are ServiceNow's equivalent of cron jobs and are essential for background maintenance, data synchronization, and automated housekeeping tasks.

When to Use

  • Nightly or weekly data cleanup operations
  • Periodic synchronization with external systems
  • Generating and emailing recurring reports
  • Closing stale incidents or requests that exceed a time threshold

Example Prompt

"Create a Scheduled Job that runs every Monday at 6:00 AM. It should find all incidents in 'On Hold' state that have not been updated in over 14 days, add a work note reminding the assignee to follow up, and if the incident has been on hold for over 30 days, automatically close it with a resolution note."

What snowcoder Generates

  • Complete scheduled script with GlideRecord queries
  • Date arithmetic using GlideDateTime for threshold calculations
  • Batch processing with record count limits to avoid timeouts
  • Logging with gs.info() for tracking execution results
  • Recommended run schedule and execution context (run as System)
  • Error handling so a single bad record does not halt the entire job

7. Fix Scripts

Fix Scripts are one-time server-side scripts designed for data maintenance, migration, and cleanup. Unlike Scheduled Jobs, they are meant to be executed manually (or once during an upgrade) and are not intended to run on a recurring basis. They live in the system as documentation of what was changed and why.

When to Use

  • Migrating data from one table or field to another
  • Correcting data quality issues after a failed import
  • Backfilling a newly added field across existing records
  • Removing duplicate records based on matching criteria

Example Prompt

"Create a Fix Script that migrates the 'u_department_name' free-text field on the Incident table to a proper reference to the Department table. Match by name, log any incidents where no matching department is found, and provide a summary count at the end."

What snowcoder Generates

  • A clear header comment explaining the purpose and expected outcome
  • Pre-execution validation (checks that source data exists)
  • Batch processing with setWorkflow(false) to skip Business Rules when appropriate
  • Detailed logging of successes, failures, and skipped records
  • Summary output showing total processed, updated, and failed counts
  • Rollback guidance in comments for reverting if something goes wrong

8. ACL Rules

Access Control List (ACL) Rules define who can read, write, create, and delete records and fields. They enforce security at the platform level, meaning they apply regardless of whether access comes from a form, a list, a REST API call, or a script. Properly configured ACLs are essential for compliance and data protection.

When to Use

  • Restricting table access to specific roles
  • Protecting sensitive fields (SSN, salary) at the field level
  • Implementing row-level security so users only see their own records
  • Securing REST API endpoints and scripted integrations

Example Prompt

"Create ACL rules for a custom 'u_employee_reviews' table. Only HR managers can read all records. Regular employees can only read their own review. The 'u_salary_adjustment' field should be visible only to the 'hr_admin' role. No one except admins can delete records."

What snowcoder Generates

  • Separate ACL records for each operation type (read, write, create, delete)
  • Row-level script using current.opened_by == gs.getUserID() patterns
  • Field-level ACLs for sensitive columns
  • Role requirements mapped to each rule
  • An evaluation order explanation so you understand which ACL wins when multiple apply
  • Testing recommendations for validating each rule with different user roles

9. Transform Maps

Transform Maps control how imported data (from CSV, Excel, JDBC, or other sources) maps to ServiceNow table fields. They include field mappings, coalesce settings for matching existing records, and transform scripts that run custom logic during the import process. They are the key to reliable, repeatable data imports.

When to Use

  • Importing user data from HR systems
  • Loading CMDB configuration items from discovery tools
  • Migrating data from legacy platforms into ServiceNow
  • Recurring data feeds that need consistent field mapping

Example Prompt

"Create a Transform Map for importing employee data from a CSV into the sys_user table. Map 'EmployeeID' to 'employee_number' (use as coalesce field), 'FullName' to 'name', 'Dept' to 'department' (lookup by name), and 'StartDate' to 'u_start_date' (convert from MM/DD/YYYY format). Skip rows where EmployeeID is blank."

What snowcoder Generates

  • Complete field mapping configuration with source and target columns
  • Coalesce field settings for upsert behavior (update if exists, insert if new)
  • onBefore transform scripts for data validation and formatting
  • onAfter transform scripts for post-import actions (creating related records)
  • Date format conversion logic
  • Reference field lookups with fallback handling when no match is found

10. Catalog Client Scripts

Catalog Client Scripts are similar to regular Client Scripts but run specifically on Service Catalog item forms and record producers. They use a slightly different API (g_form still works, but variable names replace field names) and are essential for building dynamic, user-friendly catalog experiences.

When to Use

  • Showing or hiding catalog variables based on user selections
  • Pre-populating fields with the current user's data
  • Validating catalog form inputs before the request is submitted
  • Cascading dropdowns where one variable's options depend on another

Example Prompt

"Create a Catalog Client Script for the 'New Laptop Request' catalog item. When the user selects 'Developer' as the role type, show the 'ram_upgrade' and 'additional_software' variables. When they select 'Standard User', hide those variables and reset their values. On submit, validate that at least one accessory has been selected."

What snowcoder Generates

  • Catalog-specific variable name references (not field names)
  • Proper event handling for onChange, onLoad, and onSubmit in the catalog context
  • Variable visibility toggling with g_form.setDisplay()
  • Cascading variable logic with GlideAjax for server-side lookups
  • Validation that prevents submission until required conditions are met
  • Compatibility notes for Service Portal versus classic UI rendering

11. Flow Designer Actions

Flow Designer Actions are custom, reusable building blocks for ServiceNow's Flow Designer. Each action defines its own inputs, outputs, and execution script, allowing flow builders to drag and drop complex logic into their workflows without writing code themselves. They bridge the gap between low-code flows and advanced scripted functionality.

When to Use

  • Wrapping complex API calls so flow builders can use them without scripting
  • Creating reusable approval, notification, or data transformation steps
  • Integrating external systems into Flow Designer workflows
  • Standardizing business logic so every flow follows the same patterns

Example Prompt

"Create a Flow Designer Action called 'Send Teams Notification'. Inputs: channel_webhook_url (string), message_title (string), message_body (string), and urgency (choice: normal, important, urgent). The action should format an Adaptive Card payload, post it to the Microsoft Teams webhook, and output the HTTP status code and a boolean success flag."

What snowcoder Generates

  • Action input definitions with types, labels, and mandatory flags
  • Action output definitions for downstream steps to consume
  • The execution script with RESTMessageV2 or sn_fd API calls
  • Error handling that sets output variables for both success and failure paths
  • Step configuration so the action appears correctly in Flow Designer's palette
  • Documentation annotations so flow builders understand each input and output

Choosing the Right Artifact

With 11 artifact types available, choosing the right one can feel overwhelming. Here are some guiding principles to help you pick the correct artifact for any requirement.

Server vs. Client

If the logic must execute regardless of how the record is modified (form, API, import, workflow), use a server-side artifact like a Business Rule or Script Include. If the logic is purely about the user's form experience (showing messages, hiding fields), use a Client Script or UI Policy.

One-Time vs. Recurring

If you need something to run once (data migration, backfill, cleanup), use a Fix Script. If it needs to run on a schedule, use a Scheduled Job. If it should fire every time a record changes, use a Business Rule.

Scripted vs. No-Code

UI Policies handle many common form behaviors without any code. Flow Designer Actions let non-developers use your logic in workflows. Before writing a Client Script, check if a UI Policy can do the job. Before building a complex workflow script, check if a Flow Designer Action already covers the need.

Reusable vs. Single-Purpose

If you find yourself copying the same logic across multiple Business Rules, extract it into a Script Include. If multiple flows need the same integration step, build a Flow Designer Action. Reusability reduces maintenance burden and ensures consistency.

Pro Tip: You can describe your requirement to snowcoder without specifying an artifact type, and it will recommend the best one. For example, "I need to prevent users from changing the priority of resolved incidents" might result in snowcoder suggesting a UI Policy (for the form experience) combined with a Business Rule (for API-level enforcement).

Conclusion

ServiceNow's artifact ecosystem is broad, and mastering every type takes years of hands-on experience. With snowcoder, you can shortcut that learning curve dramatically. Instead of spending hours researching the right pattern for a Transform Map or debugging the class structure of a Script Include, you describe what you need in plain English and get production-ready code in seconds.

The 11 artifact types covered in this guide represent the full spectrum of ServiceNow development: from server-side Business Rules to client-side Catalog Scripts, from one-time Fix Scripts to reusable Flow Designer Actions. Each serves a distinct purpose, and knowing when to use which one is half the battle.

The other half is writing them correctly. That's where snowcoder shines. Every generated artifact follows ServiceNow best practices, includes proper error handling, and comes with contextual comments that explain the logic. Whether you are a seasoned ServiceNow architect or a developer just getting started, snowcoder helps you produce cleaner, safer, and more maintainable code across all 11 artifact types.

Related Posts

Tutorial

Getting Started with AI-Powered ServiceNow Development

Learn how to use natural language prompts to generate production-ready ServiceNow code with snowcoder.

Tutorial

Export ServiceNow Data in Any Format

How to use multi-format export to get your ServiceNow code and audit results as CSV, Markdown, XML Update Sets, or JSON.

Technical

Flow Designer vs Business Rules: When to Use Each

A practical guide to choosing between Flow Designer and business rules for your ServiceNow automation needs.

Ready to generate ServiceNow artifacts with AI?

Start creating production-ready code for all 11 artifact types in seconds.

Try Now for Free

No credit card required.