Home > Forum > User Voice > Adding users to groups shouldn't trigger synchronizing the user properties from Azure AD

Adding users to groups shouldn't trigger synchronizing the user properties from Azure AD UNDER REVIEW
1

MVP

Hi.

adding users to groups causes an update of the user properties which downloads objects from Azure AD.
Depending on the environment it can take quite a long time.

- (7/2/2024 2:33:46 PM) Step started: Download selected objects from Azure AD if required
- (7/2/2024 2:35:44 PM) Step completed: Download selected objects from Azure AD if required (duration: 118687 ms)

While this is not a problem if the user is added via the Portal, executing the "Add user action" in synchronous mode leads to a timeout error in the browser.
https://community.webcon.com/forum/thread/5203

I don't see any reason, why adding the user to a BPS group should trigger an update from Azure AD. Could this part of the logic be removed?

Best regards,
Daniel

MVP

Something interestingly happened.

I wanted to create a few hundred BPS groups to test something unrelated to this topic.

I already had a process for creating the groups and assigning the users. I wanted to utilize it by creating another process with an item list, populate this via excel, and start the first for each row.
So far so easy I had in mind. I got distracted and forgot to add a loop to prevent that all item list rows are processed at ones.
The action for creating the sub workflows was on the path when a new workflow instance is created.
Obviously the execution failed due to the timeout issue, but while writing this post more and more BPS groups are popping up in Portal.

So, while the workflow instance used for importing the data wasn't saved, and the subworkflows haven't been created the BPS groups are being created.
The archive -/db/6/app/26/explore/all - does not contain any new workflows.

MVP

Now it is even more interesting.
It seems, that the transaction was still running and that's the reason why I didn't see the workflow instances. Neither in the Portal nor in SQL Server Management studio. I didn't think of making a dirty read.

I checked this morning and now they show up. It just took about 7 hours to complete everything.

I have now idea how this may have been implemented but they have me respect that this worked out fine. :)