View other parts:
- SharePoint Workflow Designer Tips P1
- SharePoint Workflow Designer Tips P2
- SharePoint Workflow Designer Tips P3
- SharePoint Workflow Designer Tips P5
In this part of the tips, I want to talk about abstraction concept. When you write a good workflow code and everything works just fine, you should not face a situation where you open the SharePoint designer to do some changes unless there is a major change in the logic of how the workflow works.
If you have a change management request list that is served by your workflow that requires three approvals, and you wrote the workflow code, you test your code, you put the workflow in production, and everyone is happy with it, then theoretically speaking, you should not have a case where you need to open the workflow code again. Even if one of the approvals is changed to someone else, this should not be a cause to change the workflow code.
This can be accomplished by introducing a level of abstraction, by not hard-coding values inside the workflow code, and by maintaining all configuration values in separate SharePoint list, that your workflow will read from in real time.
So now, you shall create a SharePoint List called (Workflow Configuration) for example, with two columns:
- Configuration Name (Single line of text)
- Configuration Value (Single line of text)
You then start working on populating this list with any value that you may use in your workflow. Examples are:
- If you assigning tasks, then you can put the task due date and task title in the configuration list.
- If you are calling web service, then you can put the web service URL in the configuration list.
- If you have any static values or counter values, you put them here also.
- Any switch values, for example, you may have a variable that is named (SendNotificationEnabled) and if it is true, your workflow will send notification. You can read this variable from the configuration list. That way, you can change the variable value from the configuration list without opening the workflow code.
Inside the Workflow Designer, you can read values from the Configuration List:
Just thing of this case with me. Your workflow is calling a web service, and you kept the web service variables in a confirmation list like we did here. If the URL of the web service is changed for any reason, then you can ask anyone to change it from the configuration list. No need for you to go and open the Workflow SharePoint designer, and do some changes, and hit the scary Publish button.
I usually do not keep any single hard-coded value in any of my workflow code. Usually, when I write a workflow code, I do not open the code again until there is major changes the affects the way the workflow logic is happening. Any other changes, or customization are all kept and maintained in a separate configuration list. This even include the subject of workflow email notifications.