# UiPath Provisioning Settings This section contains the information used to create, update, enable, disable, and delete accounts by triggering RPA workflows. > [!IMPORTANT] > > - UiPath cannot run multiple workflows simultaneously. This may affect the Bulk Provisioning Operations. > - Data Fabric and the CSV file must contain an attribute named `accountStatus` (a boolean attribute where `TRUE` means the account is enabled) exists in the data and that it is mapped to set the Account Status (Enabled/Disabled) in SailPoint. This attribute is only required if you want to use the Enable/Disable operation. ## Folder Configuration Configure the Provisioning Organization Unit ID if your provisioning workflows are in a folder other than the default Organization Unit ID folder. ##### Screenshot [![Provision organization ID screenshot]()]() 1. Enter your **Provisioning Organization Unit ID** if your provisioning workflows are in a folder other than the default Organization Unit ID folder. For more information, refer to [Organization Unit ID](). 2. Select **Save**. ## Operation Configuration Configure which UiPath processes to trigger for each provisioning operation. You can find release keys in UiPath Orchestrator under **Automations \> Processes**. Release keys are unique identifiers for specific RPA workflow processes in UiPath Orchestrator. Each provisioning operation requires its own workflow and corresponding release key. ##### Screenshot [![Operation configuration screenshot]()]() 1. Enter the UiPath process release key in the **CREATE Release Key** field to trigger when creating new accounts. 2. Enter the UiPath process release key in the **UPDATE Release Key** field to trigger when updating accounts. 3. Enter the UiPath process release key in the **ENABLE Release Key** field to trigger when enabling accounts. 4. Enter the UiPath process release key in the **DISABLE Release Key** field to trigger when disabling accounts. 5. Enter the UiPath process release key in the **DELETE Release Key** field to trigger when deleting accounts. 6. Select **Save**. ## Advanced Polling Settings Configure settings to adjust polling when connecting to the source. This may help resolve timeout errors that occur during provisioning operations. ##### Screenshot [![Polling settings screenshot]()]() 1. In the **Max Poll Attempts** field, enter the maximum number of times the connector should check the job status. If the job doesn't complete after the configured number of checks, it times out. 2. In the **Poll Interval in Seconds** field, enter the wait time between job status checks. Increase this value if your workflows take longer to complete. 3. Select **Save**. ## Operation-Specific Guidelines This section provides detailed guidance for provisioning operations in the UiPath RPA platform. ### Best Practices - **Return a clear result**: Always set `Status` and, on failure, set a `message` so Support can troubleshoot. The response should have the required attributes. - **Always return `OutputArguments`**: The connector requires `OutputArguments` with `Status`. Set `Status: true` on success and `Status: false` on failure. - **Return the created identity**: Always include the identity attribute in `Attributes` with the final value. - **Idempotency**: If the same operation is retried, consider designing the target system or workflow so it does not create duplicates (e.g. "create if not exists" or use a stable identifier). - **Errors**: On failure, set `Status: false` and put a short, user-friendly reason in `message`; avoid exposing sensitive details. - **Logging**: Log input and outcome (success or failure) in UiPath for auditing and support; avoid logging secrets in plain text. Log identity, which buckets had data, and outcome; avoid logging secrets. - **Atomic Operations** - If the create operation partially fails, for example if the account is created but role assignment fails: - **Option A**: Rollback the partially created account then set `Status = false`. - **Option B**: Complete what's possible, then set `Status = true`. Note the issue in a message. > **Note** > > SailPoint recommends that you rollback for consistency. - **Apply set / add / remove correctly**: In the target system, implement `Set` as "replace value", `Add` as "append to list", `Remove` as "remove these values from list" so the behavior matches the connector's intent. - **Return current state**: Prefer returning the updated account's attributes in `Attributes` (at least identity + any attributes your workflow changes) so the connector can merge and show up-to-date data. ### CREATE Operations The connector starts a UiPath job (release) when a create account request is run; the workflow receives input, creates the account in the target system, and returns a result. Configure the create release in the connector config (e.g. `createReleaseKey`). The workflow must be the one attached to that release. #### Input Arguments The connector sends a single string in the job's `InputArguments`. When the workflow parses it, it will be a JSON object (flat key-value). The input contains one key per attribute from the provisioning request. Names and sets of attributes depend on the account schema and what the request contains. For example, `Email`, `displayName`, `Roles`, etc. The connector does not send the following: - Null or empty string values - Reserved names used only for output. Names such as `Status`, `message`, or `Attributes`. The workflow can expect the following value types: - Strings - Arrays of strings - Integers - Booleans The workflow receives the same attribute names as in the schema (e.g. `Email`, `accountId`). The identity attribute's name is defined in the connector's account schema. **Input Arguments Example** > [!NOTE] > > The exact keys depend on the schema and request. ```text {"Email":"john.doe@example.com","displayName":"John Doe","Roles":["Admin"]} ``` #### Workflow Responsibilities 1. **Validate Input** - Check all required fields are present. 2. **Check for Duplicates** 1. Search the target system for an existing account with same email or username. 2. If one exists, set `Status = false` and return an error message. For example: "Account with email [john.doe@company.com]() already exists" 3. **Create Account** - Go to the user creation interface. - Fill in all the provided attributes. - Submit form / call API. - Wait for confirmation. 4. **Assign Initial Entitlements** (if specified) - Add the user to their specified roles/groups. - Assign default permissions. 5. **Verify Creation** - Search for newly created accounts. - Confirm that they exist and they are active. - If verification fails, set `Status = false`. 6. **Capture Account Details** - Scrape all account attributes from the confirmation page or the API response. - **Critical**: Capture system-generated fields (account ID, timestamps). - **Critical**: Ensure the identity attribute is captured. 7. **Return Output** - Set `Status = true` if successful. - Include a success message. - Include complete account data in the Attributes field. #### Output Arguments The connector reads the job's `OutputArguments` after the job completes. `OutputArguments` must be a JSON string that parses to an object with the following: | Field | Type | Required | Description | | --- | --- | --- | --- | | Status | boolean | Yes | `true` = success.

`false` = failure.

If `false`, the connector fails the request and can use a configured `message`. | | message | string | Recommended | Short reason or detail, especially when `Status` is `false`. | | Attributes | string | Yes | A JSON string that, when parsed, is an object of account attributes. It must include the identity attribute with the created account's ID. Other attributes returned here can be used to show the created account in the identity system. The identity attribute must be present in the parsed `Attributes` object and must have a non-empty value.

**Note:** The connector uses this to recognize the created account. The exact name is defined in the connector's account schema.

**Example:**
`{"Status":true,"message":"Account created","Attributes":"{\"Email\":\"john.doe@example.com\",\"displayName\":\"John Doe\",\"Roles\":[\"Admin\"]}"}` | **Output Success Example** ```json { "Status": true, "message": "Account john.doe@company.com created successfully in SalesApp", "Attributes": "{\"email\":\"john.doe@company.com\",\"username\":\"jdoe\",\"firstName\":\"John\",\"lastName\":\"Doe\",\"department\":\"Engineering\",\"jobTitle\":\"Senior Developer\",\"manager\":\"jane.smith@company.com\",\"status\":\"Active\",\"roles\":[\"Developer\",\"User\"],\"accountId\":\"SA-12345\",\"createdDate\":\"2025-01-10T14:30:00Z\",\"lastModifiedDate\":\"2025-01-10T14:30:00Z\"}" } ``` **Output Failure Example - Duplicate** ```json { "Status": false, "message": "Cannot create account: Email john.doe@company.com already exists in SalesApp (Account ID: SA-11111)", "Attributes": "{}" } ``` **Output Failure Example - System Error** ```json { "Status": false, "message": "Failed to create account: Target system returned error 'Invalid department code: ENG01'. Please verify department value.", "Attributes": "{}" } ``` ### UPDATE Operations The connector starts a UiPath job (release) when an update account request is run. The workflow receives the account identity and what changed (`set` / `add` / `remove`), applies the changes in the target system, then returns a result. Configure the update release in the connector config (e.g. `updateReleaseKey`). The workflow must be the one attached to that release. #### Input Arguments The connector sends a single string in the job's `InputArguments`. When the workflow parses it, it will be a JSON object with a structured shape (not a flat list of attributes like CREATE). Top-level fields: | Field | Type | Description | | --- | --- | --- | | identity attribute | string | Same value as `accountId`; the name comes from connector's schema (e.g. `Email`). | | attributesToSet | object | Key-value: attributes to **set** (replace). Values can be string, number, boolean, or array of strings. | | attributesToAdd | object | Key-value: multi-valued attributes - add these values to the existing list. Values are typically arrays of strings. | | attributesToRemove | object | Key-value: multi-valued attributes - remove these values. Values are typically arrays of strings. | | operation | string | Always **UPDATE** for this workflow. | | timestamp | string | Request timestamp (e.g. for logging). | > [!NOTE] > > Only attributes that exist in the connector's account schema are included. Identity is sent once at the top level; it is not repeated inside the three buckets. Any of the three objects may be empty `{}` if there are no `set`/`add`/`remove` changes for that category. **Input Arguments Example** ```text {"accountId":"user@example.com","Email":"user@example.com","attributesToSet":{"displayName":"New Name"},"attributesToAdd":{},"attributesToRemove":{"Roles":["OldRole"]},"operation":"UPDATE","timestamp":"Wed Feb 04 12:00:00 GMT 2026"} ``` #### Workflow Responsibilities 1. **Locate Account** 1. Use the identity attribute value to find account in target system. 2. If an account is not found, set `Status = false` immediately. Example error: "Cannot update: Account [john.doe@company.com]() not found" 2. **Determine What Changed** 1. Checkout input attributes. 2. Identify additions, such as new roles using `attributesToAdd`. 3. Identify removals, such as removed roles using `attributesToRemove`. 4. Identify modifications, such as department change using `attributesToSet`. 3. **Apply Changes** 1. Update only the specified attributes. 2. Do not modify attributes not mentioned in input. 3. Navigate to edit interface. 4. Make changes. 5. Save the changes. 4. **Verify Changes** - Re-read account data from target system. - Confirm changes applied correctly. - If verification fails, consider rolling back the changes. 5. **Capture Updated State** - Scrape all current account attributes. - **Critical**: Include identity attribute. - Include both changed and unchanged attributes (full account state). 6. **Return Output** - Set Status = true if all changes applied. - Describe what was changed in a message. - Include complete account data in the Attributes field. #### Output Arguments The connector reads the job's `OutputArguments` after the job completes. `OutputArguments` must be a JSON string that parses to an object with the following: | Field | Type | Required | Description | | --- | --- | --- | --- | | Status | boolean | Yes | `true` = success.

`false` = failure.

If `false`, the connector fails the request and can use a configured `message`. | | message | string | Recommended | Short reason or detail, especially when `Status` is `false`. | | Attributes | string | Yes | A JSON string that parses to an object of account attributes. Must include the identity attribute (e.g. `Email` or `accountId`) with the updated account's ID (usually unchanged). Other attributes returned here are merged with existing account data so the identity system shows the latest state.

**Note:** The identity attribute must be present in the parsed `Attributes` object and must have a non-empty value.

**Example:**
`{"Status":true,"message":"Account created","Attributes":"{\"Email\":\"john.doe@example.com\",\"displayName\":\"John Doe\",\"Roles\":[\"Admin\"]}"}` | **Output Success Example** ```json { "Status": true, "message": "Account updated: Changed department from Engineering to Sales, changed job title to Sales Engineer, added Sales role", "Attributes": "{\"email\":\"john.doe@company.com\",\"username\":\"jdoe\",\"firstName\":\"John\",\"lastName\":\"Doe\",\"department\":\"Sales\",\"jobTitle\":\"Sales Engineer\",\"manager\":\"bob.jones@company.com\",\"status\":\"Active\",\"roles\":[\"Developer\",\"User\",\"Sales\"],\"lastModifiedDate\":\"2025-01-10T16:15:00Z\"}" } ``` **Output Failure Example - Account Not Found** ```json { "Status": false, "message": "Cannot update account: User john.doe@company.com not found in SalesApp. Account may have been deleted.", "Attributes": "{}" } ``` ### DELETE, ENABLE, and DISABLE Operations The connector starts a UiPath job (release) when a DELETE, ENABLE, or DISABLE account request is run. The workflow receives the account identity, then it deletes, activates, or deactivates the account in the target system, and optionally returns a result. Configure the DELETE, ENABLE, or DISABLE release in the connector configuration (e.g. `deleteReleaseKey`, `enableReleaseKey`, and `disableReleaseKey`). The workflow must be the one attached to that release. > [!IMPORTANT] > > To use ENABLE or DISABLE account operations, ensure that an attribute named `accountStatus` is included in the data and that it is mapped to set the Account Status (`enabled` or `disabled`) in SailPoint. The attribute `accountStatus` is a boolean attribute where `TRUE` means the account is enabled. #### Input Arguments The connector sends a single string in the job's `InputArguments`. When the workflow parses it, it will be a JSON object with the account to modify as well as metadata. Top-level fields: | Field | Type | Description | | --- | --- | --- | | identity attribute | string | The account to modify. The name comes from the connector schema (e.g. Email). This is the only identity field sent. | | operation | string | DELETE, ENABLE, or DISABLE | | timestamp | string | Request timestamp (e.g. for logging). | **Input Arguments Example** ```text {"Email":"user@example.com","operation":"DELETE","timestamp":"Wed Feb 04 12:00:00 GMT 2026"} {"Email":"user@example.com","operation":"ENABLE","timestamp":"Wed Feb 04 12:00:00 GMT 2026"} {"Email":"user@example.com","operation":"DISABLE","timestamp":"Wed Feb 04 12:00:00 GMT 2026"} ``` #### Output Arguments - `OutputArguments` are required. The connector requires the job to complete successfully and to return valid `OutputArguments`. - If `OutputArguments` is missing, empty, or not valid JSON, the connector fails the request. - `OutputArguments` must be a JSON string that parses to an object containing: - `Status` (boolean): Required. Must be `true` for success. If Status is `false`, the connector fails the request and uses message as the error reason. - `message` (string): Recommended (especially when Status is `false`); short reason for success or failure. - Attributes are not required. The connector does not read or validate an Attributes field for this operation. **Output Arguments Examples** ##### DELETE Success ```text {"Status":true,"message":"Account deleted"} ``` Failure ```text {"Status":false,"message":"Account not found or already removed"} ``` ##### ENABLE Success ```text {"Status":true,"message":"Account enabled"} ``` Failure ```text {"Status":false,"message":"Account not found or already enabled"} ``` ##### DISABLE Success ```text {"Status":true,"message":"Account disabled"} ``` Failure ```text {"Status":false,"message":"Account not found or already disabled"} ```