Skip to main content
Users
CloudPortalLogin
  • Powered byPowered by
Introduction to Sitecore Personalize
Managing accounts and system settings
Identifying guests
Introduction to experiments
Introduction to experiences
Decisioning
View dashboards
Developer Center
Connecting to an external system
Using client-side JavaScript
Using server-side JavaScript
AI in Personalize
Glossary
  • Sitecore Personalize
  • Introduction to decisioning in Sitecore Personalize
  • Managing programmable decisions

Managing programmable decisions

A programmable decision enables your organization to use JavaScript in a decision model variant and offers the following benefits:

  • Run server-side JavaScript in a decision

  • Include real-time contextual data in decisioning

  • Leverage your organization's custom attributes for use in decision making

Programmable decisions are intended for technical users who are comfortable writing JavaScript. If you are, consider creating a decision template, a reusable, no-code decision component that can be published to the decision palette for others to drag and drop onto the canvas.

Decision templates

Create a decision template when:

  • The decision will be reused across multiple decision models.

  • You want to provide non-technical users with a configurable form, so they can adjust the decision without writing or viewing JavaScript.

Using JavaScript in programmable decisions

When writing your JavaScript, you can:

  • Access variables from other components, including programmable decisions, knowledge sources, and decision tables.

  • Use variables from data systems and analytical models made available through connections.

Each programmable decision can be assigned an output reference, a unique name representing its output. This output reference can then be used as input by other decision components such as decision tables, additional programmable decisions, or analytical models.

Reusing programmable decisions

Programmable decisions can be shared across decision models by:

  • Downloading and uploading them to another decision model variant.

  • Copying and pasting them when creating a new programmable decision in a different variant.

Working with arrays

Programmable decisions are currently the only way to access nested attributes within arrays. They retrieve the required attributes, which can then be consumed by other decisions (for example, decision tables) as input in the decisioning process.

Structuring programmable decisions

Before adding a programmable decision to a model, follow the recommended code structure. Use an Immediately Invoked Function Expression (IIFE), as shown below:

RequestResponse
(function () {
    statements
})();

An IIFE runs as soon as it is defined. This pattern helps:

  • Prevent access to variables within the IIFE expression.

  • Avoid creating too many globally accessible variables.

IIFEs are essentially self-executing anonymous functions with their own lexical scope. See IIFE for more information.

Returning MAP objects

A MAP object is a key-value data structure that lets you return multiple related values from a programmable decision, instead of being limited to a single value.

You can use MAP objects to:

  • Return multiple related pieces of information at once.

  • Enable different systems to use only the parts of the data they need.

  • Improve clarity compared to arrays, since you don't need to remember position meanings.

Sample programmable decision

The following programmable calculates a customer's tier and discount rate based on input data for nationality and gender:

RequestResponse
// Example: determine customer tier and discount
(function () {
    var returnValue = {};
    // assume `guest` is already provided by the runtime, do not redeclare it

    // --- Tier calculation based on nationality ---
    if (typeof guest.nationality === 'string') {
        if (guest.nationality === 'Denmark') {
            returnValue.tier = 'Gold';
        } else {
            returnValue.tier = 'Standard';
        }
    }

    // --- Discount calculation based on gender ---
    if (typeof guest.gender === 'string') {
        if (guest.gender === 'female') {
            returnValue.discount = 0.10;
        } else if (guest.gender === 'male') {
            returnValue.discount = 0.08;
        } else {
            returnValue.discount = 0.05;
        }
    } else {
        returnValue.discount = 0.05;
    }

    return returnValue; // MAP object
})();

When setting this up in Personalize, make sure you set its Programmable Name (example: Progammable 1), Output Reference (example: programmable1), and Type as Map.

Programmable settings should indicate the name, output reference, and type Map.
Warning

If Type is not updated, the output will be interpreted as a string.

Example response

For a sample guest input with values for gender is Male and nationality is unknown, the programmable returns a MAP with multiple key-value pairs:

RequestResponse
"outputs": [
        {
          "programmable1": {
            "tier": "Standard",
            "discount": "0.08"
          }
        }
      ]

Using MAP Outputs in decision models

You can use the outputs from a programmable decision to set up a decision table.

To use MAP outputs in a decision table:

  1. Add an input column and select the programmable decision as input. In our example, you are using the programmable named Programmable 1.

    Input column settings should indicate the name, MAP key and data type.
  2. Specify the following for the Input Column:

    • Name of Column - name to use for the input (example: Guest)

    • Map Key - the attribute from the programmable output that you want the decision table to evaluate as input. (example: programmable1.tier).

    • Choose Type - select the correct data type based on the attribute you indicated.

  3. Once the Input column is added, continue configuring the decision table as normal.

Best practices

  • Keep MAPs flat and predictable - avoid deeply nested objects.

  • Document all keys - clearly specify which MAP keys your programmable decision returns.

  • Validate inputs - check incoming params to prevent unexpected behavior.

  • Handle uncertainty safely - if confidence is low or data is missing, return null or a safe default.

  • Confirm required parameters - if no parameters are passed, the programmable falls back to its defaults. Always ensure the calling system provides the required parameters.

Do you have some feedback for us?

If you have suggestions for improving this article,

Privacy policySitecore Trust CenterCopyright © 1999-2026 Sitecore