Govern Decision Logic with Policy as Code Engine "PaCE" in Financial Services

3lkholy
ServiceNow Employee
an hour ago

Objective

When handling rules live in flow branches, business rules, and scripts, every change needs a developer and it is hard to show which rule version produced which outcome. This design guide is for FSO implementers and architects. It explains where the Policy as Code Engine (PaCE) fits in a complaint workflow and how to choose between PaCE and Decision Tables. The deciding factor is usually governance, meaning how tightly you need to control, test, and evidence changes to a rule, rather than how complex the logic is. The walkthrough uses complaint handling, but the pattern applies to any ServiceNow application or custom application you build on the platform.

What PaCE Is and Why It Matters

PaCE is a low-code framework for defining, versioning, and running policies, which are sets of rules that govern how an application behaves. PaCE lets you manage, administer, and audit policies from a centralized location. When a policy is invoked, its rules are applied to the input you provide and a decision is reached. The decision is returned to the calling application or service, which acts on it. PaCE is not tied to one product or table. It works with ServiceNow applications and with custom applications built on the Now Platform. Policies can be authored with low-code conditions or JavaScript, evaluated against a record, and invoked through the PaCE API from your application logic.

What You Can Expect

  • Fewer hard-coded rules in flows. The rule lives in a policy, and the workflow acts on the returned decision.
  • Faster, safer policy changes. Policies are versioned, so you can test and validate a draft before it becomes the current version.
  • Reuse. Standardize a policy once so it can be shared within a service and across services.
  • An audit trail. Execution records show what was evaluated and what decision came back, which can serve as evidence for audit purposes.
Note: PaCE does not supply an institution's rules or guarantee regulatory compliance. You still define, validate, and govern the policy content.

Example: Complaint Triage

To make the concept concrete, this guide walks through one scenario. Complaint handling is only the example. The same steps apply to any workflow where a record is evaluated and a decision drives what happens next.

Take the Financial Services Complaint Management workflow. A customer complaint creates a complaint case, and a complaint agent works the case. Your compliance team defines when a complaint must be reviewed by a senior handler before normal handling continues, and those criteria are reviewed and revised over time. When a case is questioned later, your team must be able to show which version of the rule applied and who approved it. The flow looks like this:

  1. A complaint case is created.
  2. The workflow invokes the current published version of a PaCE policy with the case as the evaluated record.
  3. The policy evaluates its inputs, for example complaint category, product, customer segment, or whether a prior complaint is open.
  4. PaCE returns a decision, such as Compliant or Non-Compliant, and records the execution, including what was evaluated and what came back.
  5. The workflow reads the decision and routes the case, creates a task, or updates the record.

On logic alone, this rule is small. A few inputs return one of two outcomes, and a Decision Table could express it. PaCE earns its place here because the rule changes under review and must be defended afterward, which is a lifecycle and evidence need rather than a logic need.

Note: The inputs and decision values above are illustrative only. They are not prebuilt PaCE values and they are not regulatory requirements. Your team defines the real inputs, decision vocabulary, and workflow actions.

Applying the Same Pattern to Other Applications

Nothing in the triage flow is specific to complaints. Swap the complaint case for another record, define the inputs and decisions that matter for it, and the pattern stays the same: the workflow invokes a policy, the policy returns a decision, and the workflow acts on it. Some examples:

  • Other ServiceNow applications: a dispute case that needs a specialist review, a customer service case that qualifies for priority handling, or an onboarding request that needs an additional approval.
  • Custom applications: any scoped application you build on a custom table, such as a loan exception request, a vendor intake form, or an internal compliance review.
  • Other rule types: eligibility checks, routing and escalation, approval thresholds, and required-document checks.
  • Guardrails and drift checks: identify when an application drifts from a desired state, or evaluate a change before it is made and return a compliant or non-compliant decision that the calling application enforces.
Note: These examples are illustrative. Confirm the supported tables and invocation options for your PaCE release in the product documentation.

PaCE vs. Decision Tables

Decision Tables, built in Workflow Studio, pull conditional logic out of flows and scripts. Rows are evaluated against inputs, and a configured result is returned. Both tools remove rules from flows. The difference is how much governance each rule needs around it.

Choose When it fits Complaint example
Decision Table A compact, row-based lookup of input to result. You can create a draft, test it, and publish it, but earlier published versions are not retained. Return the assignment group or queue from complaint category and product.
PaCE The rule changes under review, and you need retained versions, testing before publishing, mapping policies to records, exceptions, and inspectable executions. Decide whether a complaint needs senior review, with a versioned policy, an approved publish step, and an execution record per case.
Both The workflow needs a focused lookup and a separate governed policy check. A Decision Table picks the queue. PaCE evaluates the escalation policy.

A useful test is to ask whether you must show which version of a rule applied to a given record, and who approved that version. Publishing a Decision Table draft replaces the previous published version, and it cannot be retrieved afterward. If yes, consider PaCE. If the need is a straightforward lookup, a Decision Table is usually simpler. PaCE policies can also be reused across services, and an existing policy can serve as a baseline for another. Neither replaces the other.

Governance and Regulatory Considerations

In regulated environments, the rule itself is only part of the story. Teams also need controlled change, evidence of what ran, and a record of sanctioned deviations. The table below compares how PaCE and Decision Tables address those needs, based on the product documentation.

Governance need PaCE Decision Table
Controlled change Draft, Current, and Archived states, with a defined publish step. Draft authoring is on by default for new tables. You create a draft and publish it, and the published version is the one flows, scripts, and playbooks use.
Retained history Superseded versions move to Archived. Publishing a draft replaces the previous published version, and older versions are not retained.
Evidence of what ran Execution records show what was evaluated and what decision came back. Capture the decision in your workflow if you need one.
Reviewing changes A version diff view to compare policy versions. N/A
Separation of duties Separate admin and reader roles, so reviewers can read without changing. Separate roles for table admin, rule author, result editor, and reader, so you can limit who edits conditions and who edits results.
Sanctioned deviations Exception configuration and exception requests. N/A
Testing before go-live Test a draft before it becomes the current version. Test the draft or the published version before publishing.

Execution history can help internal auditors collect evidence for governance and risk requirements. If you also use Integrated Risk Management or Policy and Compliance Management, you can link policies to control objectives to give them business context. That link applies only where those products are in use in your instance.

Note: PaCE does not provide regulatory compliance. It gives you controls and evidence that make a policy easier to govern and defend. You still own the rule content, the approvals, and the interpretation of any regulation that applies to your institution.

Policy Lifecycle

A policy version moves through three states: Draft → Current → Archived.

  • Edit and test in Draft.
  • Publish to make a version Current.
  • Move superseded versions to Archived.

Agree on who may publish before go-live.

A policy is also a container for everything that defines it: its metadata, its versions (including policy scripts and inputs), its mapping information, and its execution history. You can define any number of policies.

Integrating PaCE into Your Workspace

PaCE is a scoped application that manages the policy lifecycle. This section walks through integrating PaCE screens into your workspace application, whether that application is built by ServiceNow or is a custom application you built. 

Note: These steps reflect the PaCE configuration model at the time of writing. Your exact setup depends on the PaCE release installed in your instance, so confirm table names, route names, and options against the product documentation for that release.

Step 0: Prerequisites

Install PaCE. Install both the policy-as-code-engine and policy-as-code-engine-ui applications on your instance. The first contains the PaCE application code. The second contains the custom components used in the PaCE workspace.

Install demo data in a non-production instance. When you install policy-as-code-engine, include the demo data. It contains the top-level PaCE routes that you copy into your application in Step 3. Do not load demo data in production.

Build general knowledge. If you need a refresher on what PaCE is and the problems it solves, review the PaCE documentation linked under What's Next, and become familiar with PaCE role management.

Define these PaCE terms for your application:

  • Document table: policies run against records from a document table that you define before runtime. It is the heart of your application, because users create policies to run against the data coming from this table. In the complaint example it is the complaint case table, and in your application it can be any ServiceNow or custom table. A calling service can also have multiple document tables.
  • Application admin role: a role in your application that inherits sn_pace.admin and can perform all create, read, update, and delete operations.
  • Application reader role: a role in your application that inherits sn_pace.policy_reader and can only perform read operations.

Step 1: Create a Calling Service Record

Navigate to the sn_pace_calling_service table and create a new record with these values:

Column Description
Name Name of your calling service.
Description Description of your calling service.
Application admin role Reference to the highest privilege role in your workspace. Make sure this role contains sn_pace.admin.
Application reader role Reference to the lowest privilege role in your workspace. Make sure this role contains sn_pace.policy_reader.

Step 2: Create a Page Configuration Record

Navigate to the sn_pace_page_configuration table and create a new record. This table stores the configuration for your PaCE features. Apart from Calling service, every column stores a JSON object that defines how its table is rendered in the PaCE UI, and each comes prefilled with defaults for the base PaCE tables.

To customize a table, create your own table that extends the base table, then pass its name as the value of the table key. For example, to add columns to policy mappings, extend sn_pace_policy_mapping and reference your table in the Mapping config.

Column What it defines
Calling service Reference to the calling service record you created in Step 1.
Document table config The document table used to render the document selection form. table is the document table for your product. label is the modal title and pluralLabel is the title of the document list. query filters the document list shown for document centric mapping. view is the UI view for the document table.
Mapping config The policy mapping list and the add mapping modal. Applies only if your application has its own UI for mapping policies to a document. table is the mapping table, query filters the mappings, objectRefField is the field in the extended mapping table that refers to the document, objectView is the view of the mapping table, and policyView is the view for the policy list in the modal.
Exception config Which exception table to render, if exceptions are enabled for your application. table is the exception table and policyView is the view for the list.
Execution table config The policy execution list. To show fields from the related document, create a database view between the execution table and the document table and use its name as table. execTablePrefix and docTablePrefix are the prefixes used when creating that view. filter is a query filter on the result, view is the UI view, and eventName is the event a calling service can define so PaCE schedules an event when an invocation request completes.

Example values, with a placeholder for your own document table:

Document table config

{
    "table": "your_document_table",
    "label": "Complaint",
    "pluralLabel": "Complaints",
    "query": "",
    "view": "pace_view"
}

Mapping config

{
    "table": "sn_pace_policy_mapping",
    "query": "",
    "objectRefField": "",
    "policyView": "pace_view",
    "objectView": "pace_view"
}

Exception config

{
    "table": "sn_pace_exception_request",
    "objectRefField": "",
    "policyView": "pace_view"
}

Execution table config

{
    "table": "sn_pace_policy_execution",
    "filter": "",
    "execTablePrefix": "",
    "docTablePrefix": "",
    "view": "pace_view",
    "eventName": "sn_pace.invocation_complete"
}

Step 3: Copy the Top Level Routes to Your Workspace

Five routes need to be copied from the PaCE workspace to yours. PaCE uses sys_ux_extension_points to keep the number of routes that integrating applications need small. In sys_ux_app_route, copy these routes:

  • pace-home
  • sn-pace-record
  • sn-pace-policy-mapping
  • sn-pace-policy-dynamic-mapping
  • version-diff

For each route, replace the App Configuration field with your app configuration, set Parent Macroponent to your application's app shell, and select Insert and Stay.

After copying the routes, create a UX page property record in sys_ux_page_property with these values:

Field Value
name pacePageConfigId
type String
value The sys_id of the page configuration record you created in Step 2.
suffix pacePageConfigId

Step 4: Test Your Integrated Workspace

Open <your-workspace-url-home>/pace-home to see the PaCE home page. You should be able to create policies, map them to documents, and review invocations.

Step 5: Author, Invoke, and Handle Outcomes

  1. Author the policy. Define inputs and decision values, then test the draft against representative records. In the complaint example, that means representative complaints.
  2. Invoke from the workflow. Call the PaCE API from your flow or script, and check the API documentation for your release for the exact invocation contract. Policies can declare API variables that must be supplied at invocation, and the policy will not run without them. In Playbooks, you can use the Invoke PaCE activity instead of scripting the call.
  3. Handle outcomes. Define what happens for each decision, execution error, or asynchronous completion.

Implementer Checklist

Before enabling this for production complaints, confirm each of the following:

  • Policy ownership: who writes, reviews, and publishes policy changes, and how changes move between instances.
  • Inputs and data: where each policy input comes from and who owns its quality.
  • Decision handling: every decision value has a defined workflow action, including a safe default.
  • Failure handling: what the workflow does if the policy errors or does not return.
  • Access: who can read executions, which may contain complaint data.
  • Workspace integration: the calling service, page configuration, routes, and page property are in place and tested in a non-production instance.
  • Validation: drafts and workflow actions are tested on representative complaints.

What's Next

Learn More

 

How are you managing handling-policy logic in complaint workflows today: flow branches, Decision Tables, scripts, or something else? Share what is working in the comments.

0 Helpfuls
  • 29 Views