Realtime workflows in CRM 2013 are useful in numerous cases. One common application I’m seeing is that a Zip Code entity is created, and when the Zip Code is selected on an entity (say, an Account or a Lead), then the appropriate record Owner can be assigned, and the City, State, Zip, Country Code, Geocoding, Account Manager, etc., can all be populated from the selected Zip Code record (a lookup on the form). However, with a realtime workflow, you may be unable to assign owner of the record, if the Owner to be assigned is in a different Business Unit, and the assigning User doesn’t have privileges to view records in that Business Unit.
It’s like as soon as you assign the new Owner of the record, you no longer have access to it. See a sample workflow below with this issue.
This didn’t seem to be a problem with workflows in the past (CRM 4.0 and CRM 2011). In previous versions of CRM, the workflows were all run in the background, so it wasn’t like the record was updated immediately (when saved, without closing and re-opening the record). Of course, if the old background process reassigned the record to a new Owner, and you didn’t have access to that record, then you wouldn’t be able to find it again or re-open it. But, now, with a realtime workflow, the problem is right in front of the User, and the workflow kind of bombs out.
Depending on a setting in the workflow, you can get this to work — but it’s not going to be pretty. If you change the setting shown below to run the realtime workflow as the Workflow Owner — and the Workflow Owner has permissions; then you can actually have the Assign Owner logic execute successfully with the realtime workflow. The problem is that this will happen while the user (who will no longer have access to the record) still has it open. That user will see a couple of funky error messages and then will most likely (eventually) close out of the record in frustration. And then, of course, the user will still never see that record again.
A cleaner way, then, would be to breakout the logic into two distinct workflows: the first workflow can do all the great stuff that realtime workflows are known for; the second workflow — which can be called as a “Child Workflow” of the first workflow — can perform the Assign Owner step. Note that the key is to make the child workflow — that assigns the owner of the record — a background process type workflow as opposed to a realtime workflow type process.
Please let me know if you run into this problem and come up with a better work-around solution!