Challenge: Your workflow is based on setting a value to a field in a record. If the workflow is running as expected, but the field value is not set on the record, how do you determine the difference between workflow actions executed by client triggers (i.e. user interaction) versus server triggers (i.e. record is loaded, record is saved)? Understanding this can help uncover why the field value is not set on the record.
Tip: Start by looking at the record in question through your regular user role. If the workflow is not accessible by you as a user (i.e. View Only Field), then it is likely the workflow action is set on a client trigger (i.e. After Field Edit) and not accessible by your workflow.
Instead, choose to have your workflow action execute by a server trigger (i.e. Before Submit) since server triggers can make changes to the record that are not accessible by a user. Alternateively, you can change the record fied visibility so that the client trigger in the workflow can make the change. Either solution will work.
Limiting the action that the workflow can perform can help improve its design. Knowing that a field should be set when a user is interacting with the interface (client trigger) versus a user event setting the field (server trigger), could change how you design your workflow. Ensuring your workflow is set up correctly will also reduce the potential for missing information. Choosing the correct type of trigger, depending on the requirements, will also optimize workflow execution. Efficiency is key when workflows execute on a client trigger, especially since it is happening when the user is interacting with the interface.