Rule Values and PowerShell Actions

Every provisioning request carries a case-insensitive collection of named properties. Conditions and actions read those values by using braces around the property name.

Property syntax

Value shape	Syntax	Example
Basic value	{PropertyName}	{CustomerID}
Array item	{PropertyName}(index)	{EmailAddresses}(0)
Hashtable item	{PropertyName}("key")	{ServiceProperties}("UsageLocation")
Service package item	{ServicePackage}("key")	{ServicePackage}("ExternalSku")

The request property collection and the service-property hashtables created by CORE are case-insensitive. Use the spelling shown in these pages anyway: it makes rules easier to compare with the source request and avoids problems when a later action creates a case-sensitive object.

Basic values

Use a basic value directly in an action parameter:

Customer {CustomerID}: {CustomerLongName}

If a property is not present, string expansion normally produces an empty string. Do not treat an empty result as proof that the underlying value is genuinely blank; first check whether the property is guaranteed for that request type.

Arrays

Arrays include values such as CustomerDomains, EmailAddresses, ServiceAccessLevels, UserServices, and UserConnectors. Indexes are zero-based:

{CustomerDomains}(0)

Do not assume an array contains an item. Add a condition or use an action designed to enumerate the collection when the number of entries can vary.

Hashtables

ServiceProperties, ServicePackage, UserProperties, SpecificProperties, and UserDBProperties are common hashtables.

{ServiceProperties}("MyProperty")

ServiceProperties is assembled from several sources. For a user service it can contain customer-service properties, user-service properties, enabled user-plan properties, and values added by the service implementation. A later source may supply the same key, so custom property names should be distinctive.

Objects and protected values

Some properties are runtime objects rather than text, including WebServiceConnection. Some values, including temporary passwords, are protected objects. Only pass these to actions whose parameter expects that object type. Do not render them into log messages or a general PowerShell command string.

Conditions

Conditions use the value syntax above and Visual Basic-style expressions used by the rules engine. Check optional values before converting them:

Not String.IsNullOrEmpty({ServiceProperties}("ExternalSku"))

For a Boolean stored as text:

Not String.IsNullOrEmpty({ServiceProperties}("Enabled")) AndAlso
CBool({ServiceProperties}("Enabled"))

Place the existence check first so short-circuit evaluation prevents an invalid conversion.

PowerShell Execute

The Powershell Execute action takes one Script parameter. Immediately before execution, the action replaces request tokens in that string and sends the resulting text to PowerShell.

For example:

Import-Module Atria.Tools
Set-AtriaConfig -ConfigKey 'Customer_{CustomerID}' -ConfigValue '{CustomerShortName}' -UseEnvironment

This action does not automatically create $CustomerID, $CustomerShortName, or a $RequestProperties variable. The values are text substitutions performed before PowerShell parses the command.

Treat substituted text as input

A customer name, email address, package value, or other substituted string can contain quotes or PowerShell metacharacters. Prefer a purpose-built action with separate parameters. If Powershell Execute is required, validate expected formats and quote values carefully. Never substitute passwords, tokens, or connection objects into the script text.

PowerShell result actions

Use the result actions when a script must add data for later rules:

Action	Result
Powershell String Get	Runs a script and stores its string result under the property name supplied to the action.
Powershell Hashtable Get	Runs a script and builds a hashtable using the configured key and value columns, then stores it under the supplied property name.

If Powershell String Get stores a value in ExternalReference, later rules can read it as:

{ExternalReference}

The stored property exists only in the current request path. It is not automatically saved to the Atria database.

MSOL Run Script actions

For Microsoft 365 automation, prefer MSOL Run Customer Script or MSOL Run User Script. These actions execute a script file through the configured MSOL web service, establish the requested Microsoft connection, expose $RequestProperties, and support named variables.

The named variable mappings become PowerShell variables in the script. They are passed by value; changing them inside the script does not change the provisioning request. See Run Microsoft Online scripts for connection types, built-in variables, and safe examples.

Discover the values in your environment

These reference pages describe properties inserted by CORE. Service schemas, service packages, Workspace item configuration, and earlier custom rules can add more. To verify a live request:

1. Send a representative request for a non-production object.
2. Capture it with a journal queue as described in the Provisioning Manager overview.
3. Check the property name, shape, and example value.
4. Test the missing-value case as well as the populated case.