Steps for Workflow (Request Template) Creation
This is a short sheet for Request Creation. This short sheet is for administrators with some system familiarity through to advanced system administrators.
If you are a new system administrator to ASM, please consult with Alemba Professional Services. You will need about 2 to 3 hours for initial training before attempting to follow this short sheet on your own.
Getting Started
See also Using Workflow Templates
Step 1 - Plan
You will need to define what your workflow should look like, use Visio or word or simply sketch it on the whiteboard in your office. Do not start until you have a plan but don’t over-think it at this stage either.
What are the requirements?
What are the naming conventions?
For Screens
For the Workflows
For new fields
Who is the stakeholder?
What decisions need to be made (If this then that)?
Do you need approvals or can it be automated, partially automated?
What data do I need to gather in order to make said decisions?
Do I need email and what content should the email have, what should the subject line say?
Is there already a similar workflow and screens in the system I can clone? Repurpose (Steal) everything you can.
If this is going to be a new service action request from the portal, can I simply use or update an existing workflow and put it on a new Service action? There is no sense duplicating your efforts. Conditional Branches mean you can have numerous “paths” in a single workflow. Often a “default” workflow can be applied to numerous service actions.
If this is a new request that will be initiated from the core application (internally), same question as above.
Once you get that working and formed loosely in ASM. Polish your workflow and screens during your testing – that is usually when gaps come to light. You just need to have a general idea at this stage.
Step 2 - Make a Change Control Spreadsheet
Start with a spread sheet/Smart Sheet/SharePoint Site – whatever works. This will form the basis of your documentation and is an excellent control document for changes and versioning the workflows. Workflows can become big and unwieldy – unless you have documented it well. If you document well, management is a breeze!
Example: You can use this to also check to make sure you have included all of the necessary details (Title, Phase, Description, etc.) on your tasks and that they are all assigned.
At a minimum you should have the following columns (this will be a living document and you may well add much more, but this will get you started):
Cover Sheet
Workflow Process Stakeholder (who is owning this workflow?)
Initial Date of Workflow inception
Date Workflow placed in Production
Workflow Version
Change dates (you can add additional columns here but if you make use of the Change controls in ASM, the details will be recorded there)
Workflow Process
Workflow Group/Owner (the group owing the individual requests as they are submitted)
Required Field Data
Task Details Sheet
Task Title
Task Phase
Task Assignment
Description (what should the person assigned this task do? Be specific)
Custom or linked fields needed for the Task screen
Email Template and Subject
Conditional Branch Rules (if applicable)
BEST PRACTICE: Always document your workflow with as much detail as you can and treat it as a living document. You will be surprised how much you forget several months or years after building one and it makes changes to workflows and troubleshooting later on very difficult.