Disabling Portal User via Rest API workflow component not working as Expected

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi,

In the onboarding request form for a Portal user, we capture both the start date and the end date. If the start date is a future date, we attempt to disable the Portal user via a REST API call in the workflow. The API call executes successfully but fails to disable the user. Interestingly, when we make the same API call through Postman, it works as expected and disables the user.

API Details:
Method: PATCH
Endpoint: {{baseUrl}}/users/c1cb7bf0-3334-40e0-b17c-794a69489afa

Payload:
{
“user”: {
“status”: “Disabled”
}
}

Note: If we update another attribute such as the user’s name using the same API setup in the workflow, the update is successful.

Please suggest, what can be the wrong in this configuration or it is a product limitation.

Regards,
Vikas

2

Looks like If everything else works, but only "status": "Disabled" fails:

  • It’s very likely a permission or timing issue
  • You can test by trying another restricted field (e.g., email verification status) to see if it behaves similarly

Also check your quotes , in payload ,check also

  • API documentation to confirm whether "status" can be updated through the same endpoint used for name changes.
  • Try setting "status": "Disabled" together with another field (e.g., name) to see if it succeeds — sometimes PATCH requires compound changes.
3

So, TMK, this is actually working as designed - but did come up in some other recent discussions so I am checking with our Internal Engineering team on it.

Portal Users are not fully/completely created until the Registration Workflow that creates them (Using a Collaboration Account Action) is ‘Complete’. Until then, they are in a Disabled State with their profile left unset (but created). Only once the entire registration workflow is in a Complete status (all actions finished), the user becomes Active and they have a Profile ID set.

So, If you are making the REST API call as the last action of the Collaboration workflow - the User is already disabled, so they are staying Disabled. Once the action finishes, the workflow is now finished, so they get pushed to the Active status automatically.

To workaround this, you can make the call to Disabled the User in a separate workflow after the Registration workflow is complete - such as in the parent Lifecycle workflow that started the registration Invite.

4

Hi Zachary,

The following error occurs when I attempt to run the disabled logic from the parent workflow.

“ Workflow failed due to validation error on the RestApiAction {:workflow_session_id=>“2e9ec089-8277-4243-b096-66a7e0d51e96”, :workflow_action_id=>“a704155e-61a2-4338-9832-79b3af6da003”}. Duplication might be possible, Possible duplicates #Profile::ActiveRecord_Relation:0x00007f6f02f265e8”

Regards,

Vikas

5

Could you provide the full API request details?

Furthermore, to confirm, you are attempting to disable the user as Zach mentioned above AFTER the user has completed the registration workflow?

6

Portal user creates under step5 (child workflow). Earlier step 6, 7 and 8 were part of the child workflow that I have moved to the parent workflow.

image
image975×359 35.3 KB

Step 6: Search the user based on his email address and update the ID in a attribute.

Step 7: Some other business functionality assigns the roles to the user. – Works fine in the child workflow.

Step 8: Invoke rest API to disable the user.

{{base_url}}api/users/{{ attribute.assignment_id }}

{

“user”: {

“name”: “A1BC X1YZ”,

“status”: “Disabled”

}

}

Note: Name get updates in the child workflow but status does not update.

7

For Step 8 can you ensure you a performing a PATCH request?

Furthermore, you can find the exact workflow action it is failing on by using the following URL → {{base_url}}/neprofile_admin/workflows/{{workflow_id}}/workflow_actions/{{workflow_action_id}}