Example Omniscript to Update Service Catalog Requests

This example assumes that the Omniscript already supports creating requests, including product selection, dynamic attribute sections, a create-submit action, and a Confirmation step. The update elements extend the existing Omniscript without changing its Create behavior.

The isUpdateMode value controls which path runs:

• When isUpdateMode is false, the Omniscript creates a request.
• When isUpdateMode is true, the Omniscript retrieves and prefills an existing request, applies update controls, and submits the changes.

Capture the Update Parameters

When a user selects Update Request on a supported record page, the host passes these runtime values to the Omniscript as merge-field tokens.

Add four Set Values elements near the beginning of the Omniscript, before the Integration Procedure Action that retrieves the existing request. Configure them in this order.

These values drive the conditional behavior for the rest of the update path. Configure each update-specific element to run only when isUpdateMode is true.

Retrieve the Existing Request

Add an Integration Procedure Action element named GetServiceRequestIPAction. The action retrieves the current custom attribute values for the record identified by recordId.

The response is stored under ExistingData in the Omniscript data JSON. Existing attribute values use this path:

ExistingData:Remote:ApiResponse:CustomAttributes

Each value under CustomAttributes is keyed by its attribute API name. In this example, the response includes attributes such as SuppliedName, Description, Status, ListOfString, and LOMParent.

If the service process defines context attributes, the response also includes them under ExistingData:Remote:ApiResponse:Context, as a sibling of CustomAttributes. Unlike custom attributes, context attributes are nested by the context definition's node names. To prefill them, see Prefill Context Attributes.

Prefill the Request Form

Add a Set Values element named UpdatePrefillSetValues after GetServiceRequestIPAction. Configure it to copy each retrieved value to its corresponding screen component.

Use the same mapping pattern for each attribute.

The left side of each mapping is the screen component's element name. The right side is the merge field for the matching attribute under CustomAttributes.

Prefill Context Attributes

If the service process uses context attributes, GetServiceRequestIPAction returns them in the same response, under ExistingData:Remote:ApiResponse:Context, alongside CustomAttributes. Prefill them in the same UpdatePrefillSetValues element. You don't need an additional element.

Unlike custom attributes, which are a flat map keyed by API name, context attributes are nested by the context definition's node names. Each node has scalar attributes, and related records appear as child-node collections. For example, a context definition with an Account node returns the account's Name value, along with a Contacts child collection in which each contact has LastName and Name values.

The response includes the following Context node. Node and field names come from your context definition.

"Context": {
    "Account": {
        "_nameFieldValue": "AccName",
        "Id": "001xx000003GaKhAAK",
        "Contacts": [
            {
                "_nameFieldValue": "ConName",
                "AccountId": "001xx000003GaKhAAK",
                "LastName": "ConName",
                "Id": "003xx000004WhMmAAK",
                "_objectType": "Contact",
                "Name": "ConName"
            }
        ],
        "_objectType": "Account",
        "Name": "AccName"
    }
}

Account is a top-level node with the scalar attribute Name. Contacts is a child-node collection in which each element is a related contact. The following merge fields map to this structure.

The first row prefills a scalar attribute on a top-level node. The second row prefills one element of a child-node collection. Omniscript doesn't include a loop element, so use the 1-based pipe index to pull a single element's field into a screen component: Contacts|1 is the first element, Contacts|2 is the second element, and so on. Use this index for a known position, such as the primary contact.

Apply the same read-only Conditional Views described in Control Attribute Editability to context screen components so that editability matches the service process configuration.

Control Attribute Editability

For each attribute with role- or status-based update settings, add a Conditional View of type Disable Read Only if True.

Note

In this condition, new is an example status value. Replace it with the lowercase value of a status in which the attribute is editable, as configured in the service process. To allow editing in multiple statuses, add each status to the condition.

On the create path, the attribute remains editable because the update rule doesn't apply. On the update path, the attribute is editable only when the user has an allowed role and the request has an allowed status. When the condition evaluates to false, the prefilled value is visible but read-only.

Configure the condition to mirror the attribute update settings in the service process. Keeping the Omniscript condition consistent with the service process settings prevents the Omniscript's update controls from conflicting with service process validation.

Submit the Update

Add an Integration Procedure Action element named UpdateSubmitIPAction alongside the existing create Submit action.

Configure the existing create Submit action to run only when isUpdateMode is false. This configuration makes sure that only one Submit action runs:

• The create Submit action runs when isUpdateMode is false.
• UpdateSubmitIPAction runs when isUpdateMode is true.

Display the Update Result

Configure the Messaging Framework settings for UpdateSubmitIPAction to publish the result in a Pub/Sub toast. Select Pub/Sub, and add these message key-value pairs.

The update path doesn't require a Navigate action. The Pub/Sub toast displays the outcome to the user.

The existing Confirmation step applies only to the create path. Configure its Conditional View to Show Element if True when isUpdateMode = false. On the update path, the toast replaces the full Confirmation step.

Review the Omniscript Element Order

Place the update elements in this order relative to the existing create elements.