View other parts:
- SharePoint Workflow Designer Tips P1
- SharePoint Workflow Designer Tips P2
- SharePoint Workflow Designer Tips P4
- SharePoint Workflow Designer Tips P5
Entities and flow charts
After planning the whole process with the right people, sit and start drawing flow charts of how the workflow will act and behave. This visualization will help you a lot when you start coding and testing your workflow implementation.
Sometime your solution will require couple of additional lists to host some data. Try to write down the columns names and types for such lists from the beginning and adopt a naming convention if possible.
What I do usually when I am planning a solution that requires workflows, that i draw the workflow flowcharts, and then for each list that I need to create, I draw an entity drawing. I like to think of Lists as Classes in .NET programming. So for example, If i need to create a list for auditing and one to hold some analysis information, I will draw the following entities, for each entity, I am listing the properties and types [column names]:
Do not test with Privileged Accounts
When you start writing your workflow code, do testing along the way for each step. My tip here is to test your workflow process with a normal user account and not with your admin or any high privileged account. I cannot emphasis how important this is.
I worked on a complex workflow once and everything worked fine as I was testing with my admin account. As the deadline become closer, I asked someone to test the workflow process with his account, and NOTHING worked. I figured out what was the problem later of course. The point here is never to test with your account or any privileged account.
Create testing environment
This is also a very good thing to do and it is a must in the development world. If you are coding a simple workflow for a list or document library, then try to create a test list or document library and code your workflow on that test list/library first.
This becomes handy when you later want to do enhancements or change something on the workflow after people start using it for long time. You will be afraid to change a working and live workflow because you cannot know if your change will affect current working users.
Instead, if you have a test environment, you could introduce your change there, test it, and then carry it safely to the production list/library.
I worked once on a solution that requires a separate sub-site, with many lists and workflows. So I created a test sub-site, create all lists and workflows there, I then did my whole testing there, and once I confirmed everything is working fine, I started to create the live sub-site with the same lists and workflows I had in the test one.
Later on, when I want to introduce new changes, I would test them in the test sub-site first so that I do not interrupt the live environment. Sometimes, when you did bad changes, the whole workflow won’t run and people start calling you. So test your workflow changes in test environment first.