Workflow - PTA - Update DN on Cube when account moved

Hello Everyone,

I have been tasked with creating a workflow to move users OU when the attribute standardOu changed. I have the workflow built out and am able to successfully move the AD account. The new challenge I am running into is that the Cube is not reflecting the OU move. I am looking for ideas on how I can update the DN on the cube and AD account without having to run a full aggregation on the AD Source. With the number of movers we have this could cause issues.

Look at a cloud rule is out of the question there is just to much risk at modifying the current rule to take the new OU move into account.

Here is my rule below I have removed any sensitive information. I have also shared screen prints with no sensitive information in them.

{
	"name": "OU Moves",
	"description": "Move user to proper OU",
	"modified": "2025-11-14T17:05:11.671984094Z",
	"modifiedBy": {
		"type": "IDENTITY",
		"id": "REDACTED",
		"name": "REDACTED"
	},
	"definition": {
		"start": "Get Identity",
		"steps": {
			"Active Directory": {
				"actionId": "sp:pag-active-directory",
				"attributes": {
					"inputForPag_address": "REDACTED",
					"inputForPag_auth_password.$": "$.defineVariable1.pagUserPassword",
					"inputForPag_auth_username.$": "$.defineVariable1.pagADUserName",
					"inputForPag_distinguishedName.$": "$.getIdentity.attributes.distinguishedName",
					"inputForPag_domain": "REDACTED",
					"inputForPag_new_parent.$": "$.getIdentity.attributes.standardOu",
					"inputForPag_port": 636,
					"inputForPag_verify_cert": false,
					"pagCommandType": "pag:active_directory:move_user",
					"pagInstanceId": "0df421d3-dd5e-4411-a8c3-ada3b1e798a3",
					"pagSpecId": "3549bbd9-c6eb-456f-a3ac-e1f3803ff8ca",
					"param_connType": "paramInline",
					"param_credentialType": "paramInline"
				},
				"displayName": "",
				"nextStep": "End Step - Success",
				"type": "action",
				"versionNumber": 1
			},
			"Compare Strings": {
				"actionId": "sp:compare-strings",
				"choiceList": [
					{
						"comparator": "StringEquals",
						"nextStep": "End Step - Success",
						"variableA.$": "$.getIdentity.attributes.distinguishedName",
						"variableB.$": "$.defineVariable.dNCalculation"
					}
				],
				"defaultStep": "Define Variable 1",
				"displayName": "",
				"type": "choice"
			},
			"Define Variable": {
				"actionId": "sp:define-variable",
				"attributes": {
					"id": "sp:define-variable",
					"variables": [
						{
							"description": "",
							"name": "DN Calculation",
							"transforms": [
								{
									"id": "sp:transform:concatenate:string",
									"input": {
										"variableB.$": "$.getIdentity.attributes.adSamaccountName"
									}
								},
								{
									"id": "sp:transform:concatenate:string",
									"input": {
										"variableB": ","
									}
								},
								{
									"id": "sp:transform:concatenate:string",
									"input": {
										"variableB.$": "$.getIdentity.attributes.standardOu"
									}
								}
							],
							"variableA": "CN="
						}
					]
				},
				"displayName": "",
				"nextStep": "Compare Strings",
				"type": "Mutation"
			},
			"Define Variable 1": {
				"actionId": "sp:define-variable",
				"attributes": {
					"id": "sp:define-variable",
					"variables": [
						{
							"description": "",
							"name": "pagADUserName",
							"transforms": [],
							"variableA": "REDACTED"
						},
						{
							"description": "",
							"name": "pagUserPassword",
							"transforms": [],
							"variableA": "REDACTED"
						}
					]
				},
				"displayName": "",
				"nextStep": "Active Directory",
				"type": "Mutation"
			},
			"End Step - Success": {
				"actionId": "sp:operator-success",
				"displayName": "",
				"type": "success"
			},
			"Get Accounts": {
				"actionId": "sp:get-accounts",
				"attributes": {
					"getAccountsBy": "specificIdentity",
					"identity.$": "$.getIdentity.id"
				},
				"displayName": "",
				"nextStep": "Define Variable",
				"type": "action",
				"versionNumber": 1
			},
			"Get Identity": {
				"actionId": "sp:get-identity",
				"attributes": {
					"id.$": "$.trigger.identity.id"
				},
				"displayName": "",
				"nextStep": "Get Accounts",
				"type": "action",
				"versionNumber": 2
			}
		}
	},
	"creator": {
		"type": "IDENTITY",
		"id": "REDACTED",
		"name": "REDACTED"
	},
	"trigger": {
		"type": "EVENT",
		"attributes": {
			"attributeToFilter": "standardOu",
			"filter.$": "$.changes[?(@.attribute == \"standardOu\")]",
			"id": "idn:identity-attributes-changed"
		}
	}
}

It’s my understanding that after the AC_NewParent, you have to reaggregate to get the account data updated in the ISC tenant. Since the DN is the account ID, changing it breaks the relationship and a new aggregation is required to get things correlated again. That is at least true when using the Service Standard Before Provisioning Rule, and I assume it is the same when using the PTA workflow Active Directory action with the Move User command.

It’s nice to see methods for such a use case that can be implemented and maintained in the UI, but I wouldn’t expect that it would change the limitation around the account ID being changed.

All that said, if you are in your workflow, and already have the account ID (ISC UUID), then you might be able to trigger a POST /v3/accounts/:id/reload using the HTTP Operation action.

If this change is handled through a beforeProvisioning rule, the distinguishedName gets updated right away at the account level because of the AC_NewParent based OU move. That makes it simple to run a single account aggregation, since the new distinguishedName is already reflected at the account level.

I’d expect the same behavior if it’s done through a workflow using a PTA action. However, in this case, it looks like the workflow might be interacting directly with the downstream AD system for its actions, without syncing those changes back to the account level. That’s essentially a flaw in the process.

The only way the account that underwent the OU move would get properly updated is by running a full account aggregation on the AD source before the workflow finishes. This ensures the newly updated attributes are captured on the account. To reduce the overhead of a full aggregation, you can enable delta aggregation on the source and then trigger the AD aggregation from the workflow at the end.