Different operators used with workflow

There are six different operators used in e workflow.

1. Set to: This operator is used to set value of the field of any data type.



2. Append with: This operator can only be used with text field. It will append specified field's value or the default value to the existing value. This operator has introduced in CRM 5.







3. Clear: This operator can be used with all data types. This will clear the field's value.



4. Increment by: This operator can only be used with decimal fields. This will increment the existing value with the specified field's value or default value.
5. Decrement by: This operator can only be used with decimal fields. This will decrement the existing value with the specified field's value or default value.
6. Multiply by: This operator can only be used with decimal fields. This will multiply the existing value with the specified field's value or default value.



Bulk or Mass edit is the great feature in CRM that allows us to edit multiple records at a time. But it will only allows us to set the value, we cannot perform above operations in bulk edit. With the help of workflows, we can perform above operations on multiple records.

Issue with Pulishing Workflow that use Custom Workflow Assembly

While there can be many other reasons for this, recently we came across a situation where a simple workflow assembly designed by us could not be used in a Workflow. If we added the reference to this workflow assembly in the Workflow, it wouldn’t publish. We would receive the following message "An error occured when the workflow was being created. Try to save the worflow again". Refer to the image below.


There was no further information to be found in the event log for this.

Upon further review of the code, it was noticed that the Namespace and Class name was the same.

Upon changing the namespace to something other than TestWorkflow the workflow designer accepted the workflow assembly and published it too.

Just wondering if this were an issue, it should not have allowed us to register the assembly in the first place. It would have been a better indicator of something being wrong with the class declarations.

For anyone else who face the same problem… it might help to check the class name.