A DESIGN PATTERN
FOR STATE MACHINE WORKFLOWS
USING SHAREPOINT DESIGNER
SHAREPOINT SATURDAY 2014
Copyright © 2013 Mark E. Vogt. All rights reserved.
Mark E. Vogt
Copyright © 2013 Mark E. Vogt. All rights
POSSIBLE & INTUITIVE:
Copyright © 2013 Mark E. Vogt. All rights
ABOUT BRIGHTSTARR…
BRIGHTSTARR excels at
delivering “extraordinary
digital experiences”…
download our white papers at www.brightstarr.com...
• Mark E. Vogt
• Principal Architect, BrightStarr
• Engineering (Aerospace, Robotics) background
• BS Aerospace – U of MN IT
• MS (ABT) Mechanical Engineering/Robotics – U of MN IT
• MS Computer Science & Applied Mathematics (Control Systems) – IIT
• Lured into Consulting by the challenges
• Alternating betwixt consulting & management by fear of boredom
• Driven into Project Management by aggravation
• Drawn into SharePoint by its revelation, simplicity & power
• Inventing & Fly Fishing every other waking minute
Copyright © 2013 Mark E. Vogt. All rights
ABOUT THE PRESENTER…
•
•
•
•
•
•
•
•
Attendees learn a design pattern for SMWF4SPD
Attendees witness some useless definitions
Attendees introduced to some practice-able definitions
Attendees understand overall blueprint for SMWF4SPD
Attendees understand overall flow of SWMF design pattern
Attendees understand key “Big Picture” concepts
Attendees understand some SMWF4SPD best practices
Speaker sneaks in some additional insights
Copyright © 2013 Mark E. Vogt. All rights
SESSION GOALS…
Copyright © 2013 Mark E. Vogt. All rights
SNEAK PEEK…
Initiating List or Library…
Processes (process instances) List…
Tasks List…
IMAGINE… a set of lists & workflows (robots) automating a single complex process…
•
•
•
•
•
•
Most key business processes are complex
Complex demands State Machine Workflows (SMWFs)
SMWFs are impractically-defined
SMWFs are thought possible only in Visual Studio
Visual Studio is a tool only for professional developers
Visual Studio-based solutions are not always possible:
• An organization has NO “professional” developers
• Custom solution are NOT permitted in PROD environment
• Design Patterns do exist for SPD-based SMWFs:
• arguably complex
• arguably unintuitive
• uncertain to be applicable to all types of business processes
• Existing process automations often have no commonality
(every solution is a unique & bewildering “one-off”…)
WHAT CAN BE DONE?...
Copyright © 2013 Mark E. Vogt. All rights
THE CHALLENGE…
State Machine:
a mathematical model of computation used to design both computer programs and
sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite
number of states. The machine is in only one state at a time; the state it is in at any given time is
called the current state. It can change from one state to another when initiated by a triggering
event or condition; this is called a transition. A particular FSM is defined by a list of its states, and
the triggering condition for each transition.
Observation: utterly useless, non-practicable definition 
Workflow:
consists of an orchestrated and repeatable pattern of business activity enabled by the
systematic organization of resources into processes that transform materials, provide services, or
process information.[1] It can be depicted as a sequence of operations, declared as work of a
person or group,[2] an organization of staff, or one or more simple or complex mechanisms.
From a more abstract or higher-level perspective, workflow may be a view or representation of
real work,[3] thus serving as a virtual representation of actual work. The flow being described
may refer to a document, service or product that is being transferred from one step to another.
State Machine Workflow:
A workflow which implements the structure & logic of a state machine.
HOW CAN ANYONE WORK WITH THESE DEFINITIONS?!!...
Copyright © 2013 Mark E. Vogt. All rights
TEXTBOOK DEFINITIONS...
State Machine:
A computer program which contains a set of event-driven and schedule-driven condition-processing
instructions which capture, track & manage the overall “state” of a system, defined as a set of individual states
representing key characteristics of that system [often termed a “vector” or a “tensor”]...
Application:
A set of computer instructions - often with a visual user interface - which implements a set of event-driven and
schedule-driven condition-processing instructions…
Workflow:
A set of computer instructions which methodically perform work according to a repeatable set of steps.
State Machine Workflow:
A set of event-driven and schedule-driven condition-processing list workflows which together work in symphony
to monitor & react to changes in the overall “state” of an instance of a larger process, pushing that state along
a variety of process path toward an eventual termination.
Terrible Horrible Secret – DO NOT READ THIS! A State Machine Workflow is… an application – one focused on
methodically carrying out a business process.
(but no one can command huge sums of money to create a mere “application”, and <apparently> they CAN
command huge sums of money if they can create a “state machine workflow”… )
[Noooooooooo!!!!!!!… the emperor has no clothes! The emperor has no clothes! Soylent green is… PEOPLE!....]
WE CAN WORK WITH THESE DEFINITIONS...
Copyright © 2013 Mark E. Vogt. All rights
PRACTICAL DEFINITIONS...
State:
A set of characteristics (attributes) which taken as a whole represent the overall
wellness/completeness of a particular system… or in our case a business process…
e.g. ALL the values of all the gauges on a dashboard
e.g. ALL the statuses of all the milestones in a workplan
e.g. ALL the dials, lights & levers on the bridge of The Enterprise
(note – IF you’re starting to think the “state” of something reads like the current values of all the items in
a checklist or shopping list, then you absolutely have the RIGHT idea…)
(DO NOT READ THIS! IF you’re starting to think “hey – then couldn’t I simply capture &
track the “state” of my process as nothing more than an item (of statuses) in a list?”, then
you’re already sprinting ahead, so please try to play dumb and let me continue…)
Event-Driven:
Responding to an event (typically a change in a state)
Schedule-Driven:
Responding – typically repeatedly – to a particular time (not event)
Condition-Processing:
Responding to a particular condition, typically the value of a state
LET’S SEE WHAT ELSE WE’LL NEED...
Copyright © 2013 Mark E. Vogt. All rights
OTHER PRACTICAL DEFINITIONS...
• Hardware:
• Server Farm (size doesn’t matter)
• Software:
• Microsoft SharePoint (year/version don’t matter - Foundation, Standard or
Enterprise)
• Microsoft Project 2010 or 2013 (better – very cool features)
• SharePoint Designer
• Visual Studio (optional-but-handy)
• SharePoint Constructs:
•
•
•
•
•
•
Sites
Libraries & Lists
Site Content Types & Site Columns
List & Library Alerts
Email-Enabled Lists & Libraries
Workflows (driven by both events & built-in timer jobs)
• SharePoint Privileges:
• Site Collection Administrator privileges
• Central Admin privileges (or at least ability to request small-but-critical mods)
Copyright © 2013 Mark E. Vogt. All rights
THINGS YOU’LL NEED…
Copyright © 2013 Mark E. Vogt. All rights
MODELING IS VITAL TO SUCCESSFUL BPA…
Quality of the process workflow = Quality of the process model…
Initiating List or Library…
1 INITIATING List (or library)
1 PROCESSES (process instances) List
1 TASKS List
6 Workflows (4 modest, 2 detailed)
1 IM Policy
Processes (process instances) List…
Tasks List…
THIS design pattern will yield a powerful, duplicate-able process automation…
Copyright © 2013 Mark E. Vogt. All rights
THE BLUEPRINT…
Copyright © 2013 Mark E. Vogt. All rights
THE BIG PICTURE: OVERALL LOGIC FLOW…
Create Task Perform task Update task Update process Create Task Perform task Update task
Update process Create Task Perform task Update task Update process Create Task Perform
task Update task…
… it’s all a big spinning circle of activity between the Processes List and the Tasks List.
• RequestsNewHandler List/Document Workflow
• Creates a new process instance in Processes List
• Can be a document or item – doesn’t matter!
• ProcessesNewHandler List Workflow
• Creates new task in Tasks List
• TasksNewHandler List Workflow
• Emails alert to Assigned Task Performer. Period.
USER PERFORMS TASK & UPDATES ASSIGNED TASK
• TasksChangedHandler List Workflow
• Decides what statuses to update in Processes List
• ProcessesChangeHandler List Workflow
• Decides what actions to take
• Creates next task in Tasks List
• TasksLateHandler List WF
• The only schedule-based condition processing WF
Several birds in the hand beats a single pterodactyl in the bush, OR…
Numerous smaller workflows working in symphony makes for intuitive,
inheritable, re-useable components…while one monstrous workflow doesn’t.
Copyright © 2013 Mark E. Vogt. All rights
THE WORKFLOWS…
Copyright © 2013 Mark E. Vogt. All rights
PEEK: REQUESTSNEWHANDLER WF…
Function: CREATE a new Process Item (instance of The Process)…
POPULATE only minimal variables…
Copyright © 2013 Mark E. Vogt. All rights
PEEK: PROCESSESNEWHANDLER WF…
Function: DETAIL new process instance…
APPLY conditions (decide which action to take)…
CREATE first task…
Copyright © 2013 Mark E. Vogt. All rights
PEEK: TASKSNEWHANDLER WF…
Function: ALERT Assigned User of new task…
Copyright © 2013 Mark E. Vogt. All rights
PEEK: TASKSCHANGEHANDLER WF…
Function: DECIDE which process statuses to update…
Copyright © 2013 Mark E. Vogt. All rights
PEEK: PROCESSESCHANGEHANDLER WF…
Function: DETECT process status changes…
DECIDE which actions to take…
CREATE next tasks …
Copyright © 2013 Mark E. Vogt. All rights
PEEK: TASKSLATEHANDLER WF…
Function: EXECUTE on a schedule…
EXAMINE every task…
CHECK for “late” tasks (leverage variables stored in a list)
EMAIL nag-mails to Assigned Task Performer (and/or manager)…
o Item
•
Title [single line text]
o ABCItem
•
•
•
•
Description [multi-line text]
Priority [A, B, C]
Condition [Green, Yellow, Red]
Notes [multi-line text]
o ABCProcess
•
•
•
•
•
Status1 [Unstarted, Started, Pending, Completed, Deferred, Cancelled ]
Status1Previous [single line text]
…
StatusN [Unstarted, Started, Pending, Completed, Deferred, Cancelled ]
StatusNPrevious [single line text]
CRITICAL POINTS:
• DON’T model process-as-document (or document-as-process) - often leads to constraints!
• DO model process-as-content type derived from Item – not Document
• Can have multiple statuses representing stages, conditions, etc for completion
• Can have multiple documents associated with a given process instance
• Multiple events all over site collection trigger multiple (small) WFs but update single process instance
• (This is essentially a “State Machine Workflow” capable of being coded by SPD instead of VS)
• Information about process is explicit & visible rather than hidden inside SharePoint
• Processes list literally becomes a dashboard into the overall status of the processes
• DO create MULTIPLE Process content types – one for every process required by a project!
Copyright © 2013 Mark E. Vogt. All rights
KEY CONTENT TYPE: PROCESSABCINSTANCE…
SharePoint can only tell you an
ITEM changed…
… so we have to find a way to
detect all of those changes!
(note – Visual Studio ListItemEventReceivers
aren’t any smarter :-O…)
Comparing current to previous detects changed status(es), which can
then be processed - this is the key to being a “state machine”…
Copyright © 2013 Mark E. Vogt. All rights
KEY: TRACK CURRENT & PREVIOUS STATUSES…
Copyright © 2013 Mark E. Vogt. All rights
LOGIC: CHANGED-STATUS DETECTION…
COMPARE current to previous status to detect WHERE “item change” occured…
APPLY CONDITIONS (logic) to any changed statuses detect…
PROCEED to next status comparison…
RESULT: this approach can respond to MULTIPLE simultaneous changes in status!
• The actual process is comprised of logic (rules)…
• Rules are just another term for conditions…
• “Logic” then is simply methodically applying conditions
• “Methodically” because there are typically LOTS of rules
The key to process automation then becomes figuring out how to provide
for 2 different types of condition handling:
1. Event-Triggered condition handling; and
2. Schedule-Triggered condition handling
Copyright © 2013 Mark E. Vogt. All rights
BPA IS ABOUT …CONDITION-HANDLING
• This is the most common
• Item in list changes because a human (or WF) changed it
• SharePoint throws up an “Item Changed” flag
• Some (not all) of our WFs wake up & start executing
• These WFs have to detect WHERE these changes occurred
• These WFs have to RESPOND to these changes
But we need some WFs to execute even when an event has NOT occurred…
Copyright © 2013 Mark E. Vogt. All rights
EVENT-BASED CONDITION HANDLING…
MOST COMMON EXAMPLE: Locate all late tasks and send out a nag-mail…
Triggering SPD Workflows to run on a scheduled basis requires a custom timer job
CHALLENGE: Sometimes custom timer jobs are NOT always possible
•
•
Organization doesn’t have development capability
Organization policy prohibits deployment of custom timer jobs into PROD farm
Useful Workaround:
Leverage the nightly timer job
already built-into the Information
Management Feature!
Create a Retention Stage which
repeats a selected WF daily, starting
immediately after creation  …
With both event-triggered and schedule-triggered WFs, much is possible…
Copyright © 2013 Mark E. Vogt. All rights
SCHEDULE-BASED CONDITION PROCESSING…
By simply color-styling the already existing,
already visible Processes list…
Processes List…
HIDDEN CEwp containing table-styling jQuery…
… that same list is transformed into a terribly-useful dashboard!
Dashboards visually represent the state of all process instances…
THIS design pattern permits HUMAN INTERVENTION!
Being a list, people can easily manually-override statuses
Useful for skipping steps, batch-updating, going back in time
Copyright © 2013 Mark E. Vogt. All rights
DASHBOARD FOR FREE !...
Copyright © 2013 Mark E. Vogt. All rights
JQUERY FOR STYLIZING DASHBOARD…
SOURCE: http://vogtland.ws/markedwardvogt/?p=1111
• MULTIPLE lists – Requests, Process and Tasks
• MULTIPLE smaller workflows on each list
• STANDARDIZED workflows (RequestNewHandlerWF,
ProcessNewHandler, ProcessChangeHandlerWF,
TaskNewHandlerWF, TaskChangeHandlerWF, TardyTaskHandlerWF)
• SECTION-OFF WF operations into STEPS
•
•
•
•
•
•
•
•
•
•
•
•
START-UP…
CREATE Workflow Variables…
PROCESS Conditions (core step)…
DEBUG (as needed)…
WRAP-UP…
INCLUDE/EXPECT “placeholder” sections for future use!
RESULT: ALL WFs start to take on a common, familiar structure 
The Document is NOT The Process
The PROCESS is The Process
The Process “OPERATES” on one (or more) documents !
Take time to RE-ENGNEER The Process BEFORE automating
MODEL The Process BEFORE automating
Copyright © 2013 Mark E. Vogt. All rights
SUMMARY – THE KEYS…
•
•
•
•
•
•
•
Process-as-item metaphor enables “State Machine” Workflow
Projects involving repeated, complex processes can be readily tracked
Complex processes can be automated in smaller, re-usable WFs
Complex processes can be partially automated, but the management fully automated
Numerous people can “feed” these items (unlike MPP files)
Numerous documents (deliverables) can be involved in a single process
Numerous criteria for completion can be readily & intuitively tracked
• TO PONDER: what’s to stop this design pattern being used
with Visual Studio ListEventHandlers instead of SPD WFs?
• (answer: NOTHING…)
Copyright © 2013 Mark E. Vogt. All rights
DISCUSSION…
• Mark E. Vogt, Principal Architect
BRIGHTSTARR
4900 Woodway Drive
Houston, TX 77056 USA
mark.vogt@brightstarr.com
• Cell: 630.781.9978
• Blog: markvogt.VOGTLAND.ws
• Personal Email: mark_vogt@hotmail.com
• Twitter: @mark_vogt
• Skype: mark.e.vogt
• WATCH for 2 new books by Mark Vogt:
•
•
SharePoint-Powered Project Management: A BluePrint & Playbook
(available on Amazon.com June 2014)
Sayings of The Wise Consultant
(available on Amazon.com Summer 2014)
Copyright © 2013 Mark E. Vogt. All rights
TO CONTACT THE PRESENTER…