I encountered a weird case when trying to set record status reason to default value on creation of the record in CRM Workflow with Status Transition Rules enabled in the entity configuration. I’ll replicate the case and implement a workaround in my trial CRM Online instance.
Let’s say we need to track payments from customers. Each payment has two statuses “Pending” and “Paid”. When some condition is met, we’ll need to update the status to “Paid”, otherwise update the status to “Pending”. It’s fairly simple. Now, let’s set things up in CRM:
- Add status reasons: “Pending”, “Paid”. and set “Pending” default value.
- Enable status transition rules:
- Create a two options field called “Condition 1” to play as a flag in our workflow.
- Create a workflow for the Payment entity:
- Make it a real-time workflow.
- Trigger on record creation, and on change of the “Condition 1” field.
- Add workflow step to check if Condition 1 is Yes, then update status to “Paid”, else update status to “Pending”
Go ahead and try out the workflow, you’ll see with an existing record, the workflow works fine. However, when you try with a new record, you’ll see followings:
- With Condition 1 set to Yes, the record can be saved and created with status “Paid”, this works correctly.
- With Condition 1 set to No, when you save the record you’ll get this error:
It’s weird that, the default status is “Pending”, our workflow also tries to set the status to “Pending”, nothing seems to be not valid here. If you set the default status to “Paid” instead, and try again, you’ll get the same error when the workflow tries to set the status to “Paid”. You’ll even get this error when you create a new record using CRM SDK.
My guess is that it’s because of status transition rules. There is no rule allow status from “default value” (in creation) to “default value” (in workflow), in our example from “Pending” to “Pending”. So the workaround is simple, we’ll check if the status is not “default value”, then we can set the status to “default value”.
In conclusion, I’m not sure if it is a bug or expected behavior. But well, it’s just one of weird things in CRM we need to keep in mind. Hope it helps!
