Implementing Dynamic Retry Workflows in Identity Security Cloud

[trettkowski (Tyler Rettkowski)]

Introduction

• Why: In Identity Security Cloud (ISC), we often interact with APIs or external scripts that might occasionally fail or require a bit of extra time. Launching a certification campaign and waiting for it to be generated before activating it is a common example. Instead of putting arbitrary “Wait” actions randomly into a workflow, you can dynamically try again, check the status, and proceed when the task is ready.
• Problem: Calling another workflow or execution where you have no knowledge of the status makes error handling and success tracking difficult. Putting all of these actions in a single workflow can also cause you to hit size or step limitations.
• Goal: A modular solution where an external “Retry Workflow” handles HTTP POSTs or Windows Server PowerShell script executions. It can retry, handle errors, and provide a polling capability from the original workflow to check the status.

Solution Overview

• Tech Stack: 4 Workflows (2 Core Retry Workflows + 2 Starting Workflows)
• High-Level Flow: Instead of executing a complex POST or PowerShell task right in your main workflow, you hand off the execution to a dedicated Retry Workflow via an HTTP Request using an External trigger. The initial workflow then polls the Retry Workflow to check its status. If the external task succeeds, the polling loop breaks and the original workflow marks as successful. If the retry workflow exhausts its retries and fails, the original workflow is marked as failed. This prevents confusion when debugging.

Key Concepts

There are several key concepts happening in this build:

1. Serial Loops with a Counter Variable: By using a counter variable that increments (using “Update Variable”) and a retrycount variable that is passed in, you can dynamically set how many retries should happen in your Serial Loop.
2. Input Validation: A “Check Input Is Complete” comparison step ensures that the caller passes the correct expected variables before proceeding.
3. Break Loops: When the task is successful, a “Break Loop” operator halts the serial loop immediately and allows the workflow to close as successful.
4. Checking Succeeded Loop Counts: When you use an “Update Variable” inside a loop, it doesn’t always keep the value once you exit the loop. To get around this, we use a comparison check using the Serial Loop’s “succeeded” count and compare that against the retrycount. This accurately determines the outcome.
5. Two Primary Use Cases:
   • Certification Launch & Poll: It takes time for a campaign to generate before you can run the /activate API call. The polling solution allows you to continuously try to activate it without hardcoding massive “Wait” actions.
   • PowerShell Execution: Pass down the parameters for a Windows Server NTLM script execution and retry it safely on the target server.
6. Bypassing the 1-Minute Minimum Wait Time: The UI makes you believe you can only input wait times in 1-minute increments. However, if you use a variable (e.g., waittime) with the value "20s", you can bypass that minimum and wait the actual amount of seconds you need. This gets passed to the retry workflow as well.
7. Modular Retry Workflows: We provided two common use cases, but you can build these for HTTP PATCH/PUT operations or Kerberos-based script executions. Since they are called externally, these retry workflows can be used from a variety of different initial workflows inside your tenant.
8. Sample JSON Payloads: The starting workflows provide you with exactly the right JSON payloads needed to call the HTTP POST and PowerShell Retry workflows.
9. Visibility & Debugging: By polling from the original workflow and returning an execution ID, any failure correctly bubbles up. Successful triggers will not mask failed back-end work.

JSON Payload Structures

When calling these retry workflows, you must pass the exact expected JSON format. If you do not have the correct structure and naming, the workflow will fail to parameterize into the correct API or PowerShell calls.

HTTP POST Request Payload

{
  "retrycount": 5,
  "waittime": "20s",
  "originalworkflow": "Test Launch Certification Campaign",
  "httprequest": {
    "url": "https://your-tenant.api.identitynow.com/v2026/campaigns/{{$.hTTPRequest.body.id}}/activate",
    "body": ""
  }
}

NTLM PowerShell Script Payload

{
  "retrycount": 5,
  "waittime": "20s",
  "originalworkflow": "Test PowerShell Script Execution",
  "windowsserver": {
    "connectionaddress": "10.0.0.100",
    "scriptpath": "C:\\Scripts\\TestScript.ps1",
    "scriptarguments": {},
    "outputformat": "text",
    "scriptsha512checksum": "",
    "powershellconfigurationname": "Microsoft.PowerShell",
    "scriptexecutiontimeout": 3600
  }
}

Note on originalworkflow:
The originalworkflow parameter is used strictly for debugging purposes. If your retry workflow is being executed from multiple different parent workflows across your tenant, this parameter makes it immediately evident where the execution originated when you look at the execution logs.

The Workflows

Below are the 4 workflow JSON files and their corresponding screenshots to help you visualize and implement the logic.

Note: Be sure to update your Client ID, Secrets, and Tenant URLs before testing these in your environment.

1. Dynamic Retry Workflow - HTTP POST Request

This is the core Retry Workflow for POST requests.

DynamicRetryWorkflowHTTPPOSTRequest20260620.json (5.7 KB)

2. Dynamic Retry Workflow - NTLM PowerShell Script

This core Retry Workflow executes a PowerShell script on your Windows Server.
DynamicRetryWorkflowNTLMPowerShellScript20260620.json (7.5 KB)

3. Test - Launch Certification Campaign

The initial testing workflow that creates a campaign and calls the POST Retry Workflow to activate it.

TestLaunchCertificationCampaign20260620.json (8.3 KB)

4. Test - PowerShell Script Execution

The initial testing workflow that passes variables down to the NTLM PowerShell Retry Workflow.
TestPowerShellScriptExecution20260620.json (7.0 KB)

Considerations & Best Practices

Important: Always test this pattern thoroughly in a sandbox tenant before promoting it to your production environment to ensure it behaves exactly as expected.

• Permissions & Credential Handling: Ensure your service account or Personal Access Token (PAT) used to execute these external workflows follows the principle of least privilege, granting only the necessary authorization scopes (e.g., idn:campaigns:manage). Avoid hardcoding credentials in plain text.
• External Trigger Security: When exposing workflows via external triggers, securely manage the generated Client ID and Secret. Treat them as sensitive credentials, rotate them periodically, and restrict their usage to authorized internal callers.
• Safe Retry Behavior for POST Requests: Be cautious when retrying HTTP POST operations. Ensure the target endpoint is idempotent or that you are properly handling potential duplicate resource creations if a request times out but was actually processed by the destination server.
• PowerShell Execution Safeguards: For Windows Server script executions, strictly validate any arguments passed into the script from the workflow to prevent injection attacks. Always enforce script execution timeouts (as demonstrated in the payload) to avoid hung processes on your target server.
• Error Handling: Many of the HTTP Request steps inside the retry loop will intentionally log as failures until they finally succeed. Use the execution ID and status check in your polling workflow to understand the final result.
• Payload Variables: The variables configured in waittime (such as "20s") must be strictly formatted if you are trying to bypass the 1-minute limitation.

Conclusion

• Summary: Using a parent/child workflow model via external triggers allows you to create modular retry functionality. By passing parameters in and polling for an execution ID, you achieve better error handling without cluttering your workflows.
• Call to Action: If you have any questions or try this out for other use cases like PATCH requests or Kerberos scripts, please leave a comment below.