Sync Local Accounts running before demotion script finishesSolved

Hello,

Thanks for reaching out to Hexnode Connect.

If you add both the Execute Custom Script and Sync Local Accounts actions to the exact same automation sequence, they are queued and dispatched to the device at nearly the exact same time. The sync action does not pause to wait for the script logic to fully execute on the operating system.

If the sync command reaches the device before your demotion script has finalized the local account change in Windows, Hexnode will scan the device and simply report the previous Administrator status again.

For this specific workflow, you need to trigger the Local Accounts sync only after the script has fully completed the demotion. Rather than running back-to-back portal actions, the most reliable approach is to add logic within your script to verify the account demotion locally, and then trigger the Hexnode Sync Local Accounts as the absolute final step of that script. This ensures a strictly controlled post-script inventory refresh.

I hope this helps. If you find any more issues or need further assistance feel free to reach out.

Best regards,
George,
Hexnode UEM

Looking closely at the Action History tab, the script and the Sync Local Accounts action show the exact same timestamp, so they are definitely firing together. The sync command also reported as successful, which was confusing since the portal didn’t update right away. I guess a successful sync just means the scan ran, not necessarily that it captured the new state.

For now, we are treating the delayed update as acceptable since it does eventually refresh on its own during a regular check-in, but we will definitely revisit the API-triggered sync if we need the Self Service request flow to be completely instantaneous. Thanks for the breakdown!

Hello,

A successful Sync Local Accounts command simply means the remote scan action itself completed without error on the device; it does not guarantee it captured the intended post-script state if the OS had not yet committed the role change.

If you choose not to use an explicit post-script API sync, the system will fall back to relying on the regular local account inventory refresh window. This is exactly why you see the updated Standard role eventually appear during the next scheduled sync cycle. The key takeaway for automation building is ensuring your syncs happen after the OS-level change is finalized, not merely after the portal has queued the action.

I hope this helps. If you find any more issues or need further assistance feel free to reach out.

Best regards,
George,
Hexnode UEM