This is the first presentantion of our Guest Expert series featuring SharePoint MVPs talking about workflows and process design in SharePoint. The presentation explains the limitations of SharePoint Designer in deploying workflow, when this tool is enough to model business processes and when you need to look for other solutions.
AGENDA
After watching this webinar you will learn how to:
✓ Improve processes with workflow logic
✓ Select the type of workflow which works the best for your process
✓ Use Visual Studio to create custom workflows for large-scale complex processes
✓ Choose SharePoint Designer, Visual Studio or 3rd party solutions depending on your needs
SPEAKER
Bjoern H. Rapp is Senior Software Engineer at Steria Norge, Microsoft SharePoint MVP, and the author of the book "Beginning SharePoint 2013 Workflows" . In his native Norway he is a leading figure of the local SharePoint community, organizing such events as SharePoint Saturday Oslo. Visit his blog: SharePointViking.com
13. SharePoint Designer 2013 Limitations
• A general tool for creating non-code
SharePoint solutions
• Creating and modifying site assets, site columns and
content types
• Creating and modifying sites and lists
• LOB Data Integration
• Web publishing
• Workflow Creation
• Not a 100% clean Workflow authoring
application!!
14. SharePoint Designer 2013 Limitations cont.
• No native built-in visual designer
• Text-based designer default, not
optimal for many business users
• Visual Designer only available via
licensed version of Visio 2013
Professional.
15. SharePoint Designer 2013 Limitations cont.
• Limited extensibility
• Building custom actions requires
programming skills and access to Visual
Studio
• Insecure future regarding Forms support
• InfoPath forms requires Enterprise
version of SharePoint 2013
• InfoPath will be deprecated in future
SharePoint versions
16. SharePoint Designer 2013 Limitations cont.
• Limited debugging options
• Only validation and well-formed checks
available via «Check for Errors»
• No in-place testing capacity.
• Debugging via adding lots of «Send to
History» actions!
17. SharePoint Designer 2013 Limitations cont.
• Maybe most important of them all....
• SharePoint Designer is a potentially
«dangerous» tool in the wrong
hands..!!!
• Many organizations impose restrictions
on the use of SharePoint Designer.
19. Datapolis Process System Overview
Workflow Designer (former Datapolis Workbox)
• Visual process designer for business users
• Visual activities designer for technical users
Workflow as Application and Application in Workflow
• Any workflow can be converted into Application
• Applications can be built using any external tool
• Applications be used inside workflows and by external solutions
Central Administration
• Single list to control all workflows across the farm
• Workflow and Application maintenance permission structure
• Performance monitoring diagnostics
23. Applications – unique selling points
Process 1
App 1
App 2
App 3
App 1
Pull common processes into a single repository
• Fast changes adoption in the whole workflow system
• Coherent and up-to-date process definition in the whole system
Parallel sub processes
• More then one task can be executed at the same time
• The workflow definition remains clear and understable
• One process executed many times at the same moment
24. Build a workflow for pre-install contact..
…another one for the post-install contact
32. Examples of monitorable processes
How many items finish each hour, day, week?
How regular is the flow?
Which item took the longest to complete the process?
How long did that item take?
Which item completed the process fastest?
How long did that item take?
Which sub-process takes the longest?
How long does an item wait in a given state?
The main module of Datapolis Process System is workflow designer.
DPS has two additional groups of functionalities.
The first one is named Applications. Simply speaking any workflow can be transformed into an application and reused in other workflows. You can also create application in external solution. We can build workflows using applications like Lego bricks.
The second group of functions is called Central Administration. Now it’s possible to manage the entire workflow system from one central place.
This is the graphic designer for a workflow with the green start circle and the red end circle. Here you click on an icon in the tool tray to the left and drag it onto the design board. Creating a state action diagram using the Datapolis process system is a simple matter of drag and drop. Use the state as a virtual pile and the action as a means of moving the item from one pile to another.
Thanks to applications it will be easier to keep the whole system in order. For example, if you use one procedure in many workflows and the procedure is changed you need to modify all workflows independently. In DPS it is enough to change one application in one place and all workflows will be modified automatically
A workflow can be made into an application
An Application can run inside a workflow
A workflow can access external data through an application
Depending on where the data is stored, you may create multiple workflows—one for each data storage location. Most of the time a person will kick off an action, but it is possible to set a timer that will wait for a period of time then at a set date and time or after a set interval, the system will launch the next action. We can set the install confirmation timer to go off at the time of the scheduled install requiring the installer to report what happened. After we get Install request workflow finished we can package it as an application. Here the application is represented by an aqua square. We can also package the install confirmation as an application represented by an orange square. We’ll use these application squares later as we embed them in the overall order entry process.
So after the applications have been created they are accessible as icons in the upper right hand side of the designer window.
As I mentioned in a previous slide, a workflow application can be reused inside another workflow. This ability permits the workflow designer to control changes and reuse workflows in multiple locations. This simplifies the workflow management process.
After creating the workflow on the orders list, we will drag and drop the pre-packaged Install request workflow on the pre Install confirmation state. This allows the user to post an install request on the installers calendar, before moving the order to the waiting install state. We will also attach the orange Install confirmation workflow to the Post Install Confirmation state. The Install Confirmation can send data outside SharePoint to the billing system to initiate the invoice.
In workflow terminology you can define an activity as a detailed process or event that takes place in an action. An action can contain several activities. To define new activities you open a new designer. Activities can do almost anything. They can be placed in containers and executed only under certain conditions or can be executed repeatedly. They can even perform specialized procedures.
Until now we’ve just been talking about the process designer and the system actions. But the most important parts of a process are the process participants, the people who work with the data to cause things to happen in the real world. Datapolis process system assumes two roles for every new workflow. The author is the person who initiates the workflow, in our case the person who enters the order. By default we have an all users role so that all SharePoint users could do all workflow actions unless we choose otherwise. Sometimes only one person manages items in a given state, but usually several individuals work as a team to fulfill a role. For our process we have a sales team, a customer service team, and an Installer team. I’ve colored the states to match the team in charge of that state. So the Sales team is tan, the customer service team is blue, and the installer is gray. I made the final confirmation state pink to match the manager. Since they each have separate roles, lets define what actions each team can and should perform. Incidentally, this is a slightly different sample workflow.
Let’s turn focus to how we can monitor the Workflows in DPS.
With Datapolis Process System it is possible to see each instance of a running workflow. On this slide I have 11 instances, 11 items. 5 are in the Analyze event state and 5 are in the finished state and one is not showing. Noora has 9 instances in the New LMA state.
We can look also at the history of each instance and determine exactly when the instance started, what actions were initiated and what activities were performed and when.
Mention here the clear differences to the lacking monitoring capabilities in SharePoint Designer.
DPS Management, available from its own page in Central Administration
From Central Admin, you can drill down to list Datapolis workflows on a per site level.
Easy to use logging configuration options mapping the Standard SharePoint logging levels for the Windows Event log and the ULS log.