Social media


Wednesday, December 23, 2009

Merry Christmas!

Tuesday, December 22, 2009

Scope of the release 1.5.5

Sorry for not publishing this earlier - most of the Workbox team is currently off for holidays after the exhausting release 1.5. We will start working on the new release in January.
As always - after releasing the big release we are going to do the sub-release, that will be shorter and will only improve the existing features, without introducing any big changes.
In the next release of Workbox (expected by the end of January) we will introduce the following functionalities:
  • "Current item" check-box - you will be able to quickly point to the current item on item activities instead of defining the list and item filter "ID=[Current item ID]".
  • "As current user" check-box - you will be able to define on item activities, that in item modification history the "modified by" will be set to the user launching the action instead of the "system" account
  • "Do not change version" check-box - you will be able to set on the "edit item" activity that the changes should be done without adding new version to the item. Very useful when editing multiple fields.
  • Launch form templates - you will be able to save your launch form as a template and use it on another action in the same workflow
  • Read only fields on launch form
  • Permission level matching - currently permission levels are not matched during workflow migration. This will change in the new release
  • Activity grouping - you will be able to group selected activities on the activity diagram, fold such group, copy it, move, etc.

  • "If" activity name will be displayed on the diagram
We will also optimize the workflow deployment mechanism to speed up the workflow deployment process and fix any bugs from the previous releases.

Mathematical operations in Workbox

As you may have noticed, inputting "3+5" in the activity parameter will return "3+5". What to do, to receive (in this case) "8"?

To perform the calculation you need to pass the equation to a variable using "set variable" activity or use the "calculate" math function.
NOTE: The variable which will receive the equation must be of "double" or "integer" type. Only then the calculations will be performed.

Later, you can use this variable in other lookup fields.

So, for example - you want to take data from one SharePoint item field, subtract it from another field and put the equation result into another SharePoint item field. To do this:

  • In the activities window add "edit item" activity and double click it to enter the details
  • Pick the list, filters and field you want to add the new value.
  • Open the new value field
  • Click on the "Lookup" button
  • Go to functions -> math ->calculate
  • Click on the value textbox, new window will appear
  • Pick (using lookups) value of the selected SharePoint item field
  • enter minus sign
  • The equation should look like this (without quotation marks) "[list_name - field_name] - [list_name2 - field_name2]"
  • Click ok,
Now Workbox will do the calculation instead of treating the values as text.

You can use the following functions:
  • ^
  • +
  • -
  • /
  • *
  • cos
  • sin
  • exp
  • ln
  • tan
  • acos
  • asin
  • atan
  • cosh
  • sinh
  • tanh
  • sqrt
  • cotan
  • fpart
  • acotan
  • round
  • ceil
  • floor
  • fac
  • sfac
  • abs
  • log
  • %
  • >
  • <
  • &&
  • ==
  • !=
  • ||
  • !
  • >=
  • <=
and constants:
  • euler
  • pi
  • nan
  • infinity
  • true
  • false

Tuesday, December 15, 2009

Item field permissions on for multiple workflows

If you have more than one Workbox workflow on a SharePoint list item or document in library, all of these workflows affect permissions for item's fields.
The general rule is that Workbox is taking the sum of all permissions for given user. So if in workflow A in state A1 you have permissions to view fields X,Y and in workflow B in state B1 you have permissions to view fields W,Y,Z then you will see fields W,X,Y,Z. If in state A2 you do not have permissions for any column, and in workflow B you are still in state B1, then you will have the W,Y,Z columns visible.
The same rule applies for the "edit" permissions.
Since there are no "deny" permissions, if you are included in a role that has permissions to see a column - you will see it, regardless of settings from other workflows.
If you are also using another Datapolis product - SCP, then SCP settings are ignored when the workflow kicks in. This mean that Workflow settings override SCP settings and you will get what you have defined for workflows in given states.

Hotfix for 1.5

We have released a hotfix for version 1.5.
The most important fix is the wrkstat.aspx error - please see details here.

As always you can download the newset version here

Tuesday, December 1, 2009

Workbox 1.5 upgrade - best practice

Workbox 1.5 is here. But since we have change a couple of things (the most invasive one is the change of feature scope - from site collection feature to site feature) upgrade should be taken with a bit of care.

Before you start we recommend reading the "Upgrading..." chapter from installation instruction.We also recommend reading this page about new features.

This is the recommended upgrade scenario:
  1. Download Workbox 1.5 from here.
  2. If you do not want to turn on the Workbox feature on all sites of chosen web application please note the sites where you want to turn the Workbox feature.
  3. NOTE: Uninstalling and installing Workbox will cause the workflow actions to be unavailable. Make sure to perform the upgrade when users are not using Workbox workflows.Expected downtime is around 15 minutes. 
  4. Go to the location where you have your Workbox setup files (c:\program files\datapolis\workbox setup by default).
  5. Run setup.exe and choose the "remove" option.
  6. Do the IIS reset.
  7. Run the new installer
  8. Extract the files to Workbox setup 1.5 folder (or someplace different than the old setup files).
  9. Run the setup.
  10. Select the web applications. If you do not want to turn on the feature automaticaly, uncheck the checkbox.
  11. Run IIS reset after the setup (machine restart recommended).
If you do not follow the above steps and just select the "upgrade" option in the installer you can expect 2 things:
  • your machine might (but does not have to) cache the DLL's which may lead to some strange behavior (deployment problems, workflow stopping after start and lack of workflow actions)
  • Workbox site feature will not be activated anywhere, so you will have to activate it manually on every site.
  • Q: How will new version change my workflows?
  • A: We tried to make the new version as much backwards compatible as possible. There were some areas where it was impossible (for example the "BR" tags in mail messages). Generally your workflows should work without any problems with the new version, users will have a little different (better) experience with action launch form. The only thing that might work differently are the e-mails - you might lose some line spacing there. Please see the "What's new" article in Workbox help or on this page and help for the "Import/Export" and the "Launch form"
  • Q: Won't the uninstall destroy my workflows?
  • A: No. The workflows that are already running will not be affected by the uninstall. The only problem that might occur is with new workflow starting during the uninstallation or the users launching some actions. Also users will not be able to use the workflows until the new version is installed. We recommend doing the upgrade when no one is using Workbox workflows 

  • Q: I don't like the new functionality/something went wrong. Can I roll back?
  • A: Yes, you can. Simply use the new installer to deinstall version 1.5 and resintall the version you had previously.
If you have any questions or comments regarding the upgrade please leave your comments underneath this post.

Workbox 1.5 is ready!

After 4 months of development we have released version 1.5 of Workbox for SharePoint (build

In this version:
  • action launch form
  • Saving workflows in STP
  • Action URL
  • Folder in item activities
  • Logical funtions
and much more - see this page for full info.

You can download the new release from here.

If you are upgrading from version 1.4.3 or earlier please make sure you read the installation instruction. Release 1.5 brings in some changes that might stop your workflows. In general - please de-install old version using old installer and install the new version using the new installer. After setup turn on the Workbox feature on every site you would like Workbox workflows to work. Please see this post for details.

Thursday, November 26, 2009

Saving workflow solution in site template.

Starting with release 1.5 Workbox allows you to save workflow definitions in site templates. This means that you can prepare a SharePoint site with multiple lists and workflows and deploy it to different locations. All you need to do is to save site as a template and use it to create other sites. Workflows will be deployed automatically on newly created site.

In order to get your workflows to work properly after you create new sites from STP, you need to prepare the STP correctly.

Follow these steps to create a properly working workflow solution:
  1. Configure a site that you want to save as template. Create all lists and workflows you need. Test if everything is working as it should.
  2. Delete all content you do not want to save inside the template.
  3. TURN OFF the Workbox feature.
  4. Save site as STP. REMEMBER TO CHECK THE “Save content” CHECKBOX.
When you want to deploy a solution:
  1. Create a new site using your STP as a site template.
  2. After the site is created, turn on the Workbox feature.
  3. Wait for the feature to activate.
  4. After all the workflows are matched, you will receive an e-mail with log of the match process. If there were any errors during lookup matching, you will get notification. This log is also accessible from the Workbox workflow administration page. Workflows that did not match correctly will be listed in the log and marked with red exclamation marks on the workflow list.
  5. If there were workflows which haven’t been matched properly, open each of them in Workbox Designer. You will be taken automatically to the matching form, where you would be able to manually match all the lookups that could not be matched automatically. When finished, deploy the workflow.
NOTE: Instances of running workflows are not saved. This means that if you have any working or completed workflows on items, these workflow instances will be lost. This includes workflow history for all items.

Here are few facts that will help you to understand the workflow deploying process:
  • Workbox workflows are dependent on object GUIDs. These are unique IDs that allow Workbox to identify SharePoint elements (sites, lists, items). When you create new site, these GUIDs are generated anew. This causes workflow definition to point to locations it cannot recognize. To fix this problem, workflow lookups must be matched again after the site is created.
  • Workbox tries to match workflow definitions when you turn on the Workbox feature. This is the same matching functionality you know from when you import workflow definition from file. When you turn the Workbox feature on, Workbox will automatically try to match all the workflows and deploy the workflows that were deployed when the template was created.
  • Workbox may be unable to match lookups automatically if your template is referring to some objects outside the site – other sites, permission levels, SharePoint groups – that do not exist in the new environment. In such case you need to match those lookups manually. Workbox will detect such situation and tag unmatched workflows. If you open them with Workbox Designer, the matching window will come up, allowing you to manually point the desired objects. When corrected, workflow must then be deployed.
  • Workflow definition is stored as a file on SharePoint library. To include the workflow into the site template, you must include the content in the site definition by checking the “Include content” checkbox.
  • Workflow instance data is stored outside the site. That’s why information about any running or completed workflows will be lost. We advise you to save to definition only the data that is necessary for the solution to work (e.g. workflow libraries, mail data, etc).
  • Aside from lookup matching, Workbox also performs authorization provider match. It determines whether you use Active Directory or Forms Authentication and tries to match domains or membership providers with those which can be found in a new environment. If it cannot find a domain or membership provider with the name provided in a workflow definition, it assumes the first found domain or membership provider, ignoring the internal NT AUTHORITY and SHAREPOINT domains.

Tuesday, November 24, 2009

Deleting list permissions vs. item permissions

We have received an issue report from one of our partners. They have encountered a situation where the Workbox 'List permissions’ activity changed an item security. After looking into this problem we have learned that this is a standard SharePoint behavior, but it needs a bit of explanation.

Workbox allows you to create a workflow that will set SharePoint list permissions. This is achieved through an activity called "List permissions". One of the activity parameters is the "Delete existing permissions" check-box. If you select it Workbox will remove all existing list permissions. This allows you to quickly clear the list permissions and set them exactly the way you want them.

There is one thing that you need to remember about if you break permission inheritance for an element. In general - if you remove a user from the list, then SharePoint will automatically remove this user's permissions from all items in this list. This is because user needs to have access to the list to have any permissions to the item. You can see this behavior if you add someone permissions to some item when they had no permissions assigned directly to the list. The user will get the "Limited access" permission to the list.

Having that in mind, when you select the "Delete existing permissions" check-box ALL permissions to the list will be deleted. This will result in deleting ALL permissions to the items with broken inheritance. So please be very careful in using this settings as it can mess your item permissions.

Friday, November 20, 2009

Workbox and SharePoint 2010

You are probably wondering what are our plans regarding Workbox compatibility with SharePoint 14.

The general answer is that we are definitely going to support SP2010 and we want to have it ready for the official release of SP14. Probably we will start some R&D next week, but we cannot promise the SP 14 compatible version this year.

Availability of Workbox for SP2010 depends on how much changes Microsoft has made in the API. We will need to change the references from the SP 12 to the SP 14 DLLs, but we are not sure if Microsoft pledge, that old application will work can be taken literally. The amount of work depends how many things we will need to adjust to the new API. We will post new information as soon as we know more on this issue.

Wednesday, November 18, 2009

Workbox on Twitter

Now you can quickly see what is going on with workbox - simply follow us on Twitter -

Friday, November 13, 2009

News about Workbox

Recently we have been very quiet about Workbox. This is because there have been a lot things going on that kept us from posting. In the previous weeks we were focused on making bigger impact with Workbox in the nearest future.

I can now reveal few things what you can expect soon.

The most important one is of course the new release. I know that you are waiting impatiently for the new features and I can assure you that we are just as impatient to give them to you. The changes we are introducing are very wide and require throughout testing on our side, so you have to wait a bit longer. We are now in the beta phase - polishing all details, checking different scenarios, focusing strongly on backward compatibility to make sure you workflows will work properly. One thing we haven't told you is that we are going to introduce Spanish version of Workbox.

The next thing is that we are preparing new web site, that will be strongly focused on Workbox. We are also going to be more active on the social sites to spread the word on Workbox and keep you informed. Below you can see how our main page will look like.

Third great area where we have invested is getting ready for the SharePoint 2010 and Project Server 2010. We have attended Project Ignite in Prague to get more details on workflows in PS 2010.

Blog commitment

In the recent weeks we all have been very busy getting the release finished.

Unfortunately there is also a lot to be done in related areas - partners, marketing, new opportunities - so this blog has suffered and no new updates appeared here.

That's why I have deceived to make a commitment to post at least 1 post weekly to keep you up to date on what's going on and also give you more insight on Workbox. You can expect new post by Friday each week.

Thursday, October 15, 2009

Sneak peek - Viewing the values provided by user on action launch form (variables)

As you probably might know, you can ask your user to provide some information when launching the action.
This data is then stored inside the workflow. You can surface it by using the "edit item" activity and putting this value unto some SharePoint field, or for example send it in the e-mail and so on.

In the new release we will also display that data in the workflow history. Thanks to this new functionality you will be able to easily check what data the users have provided in the launch form.
You can see how it looks on the screen-shots from the beta version:

Friday, October 9, 2009

Rich e-mail messages

You might have come to a problem, when you had to send an e-mail with Workbox and it was, well .... ugly.
Your only option to make it look better was to use HTML with styles and format entire message in the not-so-convenient textbox. We do not have any good Silverlight control that would allow you to create nice looking messages in the Workbox, but we have a workaround.

The workaround is to create a separate list, where you can use the SharePoint richtext box to define the message. For example - have a list with 2 fields - one would be the title, which would define what kind of message this is and another is a multi-line textbox field with rich content enabled. Then inside the designer just use lookup to make the workflow use this field value in the e-mail. This has also a great advantage that you can change e-mail message without redeploying workflow.

How about using lookups in such message?
You have two options - either you combine the message from few elements and insert lookup between them or you can use the "Replace multiple words" to replace a chosen tags with lookup values.

One thing to remember - text in Sharepoint textboxes is using SharePoint styles. Make sure to choose the font family and size to get the same styles in your message.

Wednesday, October 7, 2009

Hotfix 1.4.3 is released

Because the release was postponed we have decided to publish the hotfix. It is fixing the bug that is causing the designer stalling (see this error). There is also one fix to the installer, which is making the installer more resistant to the errors.
As always, the new version is available here

Workbox vs. SharePoint Designer

We have created a table that compares SPD 2007 and Workbox. You can download it from here

Sunday, October 4, 2009

Release postponed

I should have published this 2 weeks earlier, but I just forgot.

The release of version 1.4.5 is posponed. We were having some staffing dificulties (few vacations, another project, 2 sick leaves, one honey moon) which have led to time-line slip. Most of the functionalities are ready, but we need to test them, which will take us 2-3 weeks. The more specific date will be published next week.

Sorry to all who were expecting the release - we are doing all we can to get it ready as soon as possible

Friday, September 25, 2009

Coping or moving your lookup

Lookups are very powerful and allow you to greatly enhance your workflow. They are also sometimes time consuming to configure (especially when using functions or embedded lookups).

As you already might have noticed it is impossible to copy anything from the rich textbox that allows you to configure the lookup. What can you do if you would like to use the same lookup somewhere else or move the lookup to another place?
This can be a really important feature when after defining some lookup you realize that you would need to do one more operation with the lookup (for example trim it or add "5" to a calculated value). What to do, apart from creating the lookup from scratch?

The solution for this problem are the "used lookups". As you might have noticed, when you create new lookup a small context menu appears, allowing you to create a lookup based on another lookup.

If you would like to copy an already created lookup, simply choose it's new location and select the lookup that should be copied from the list of used lookups. If you want to move the lookup, simply delete the source lookup AFTER creating the copied one. If you would like to insert a used lookup into a function do it the same way as you would move the lookup - create a new lookup in the function, based on the existing one and then delete the first one.

One more thing - new lookups do not modify the lookups that were used  to create them. The existing lookups act as templates for the lookups. You can modify the new one and be sure that the existing one will not be modified.

Tuesday, September 22, 2009

Automatic item permissions in SharePoint

NOTE: See important performance information in this post

We have been asked by one of our users

"Our business need is to allow users access to particular items only if they are listed in a 'points of contact' field in the item. This appears to be possible but not clean with MOSS.

Is this something your product can help with? If not, do you have a suggestion?"

Workbox allows you to create a solution for this problem in minutes.
We have created a short tutorial to show you how you can easily achieve this scenario by using Workbox workflow.

You can also download a definition of this workflow to try it our on your environment.

Generally you can use the "Set item permissions" activity to set the permissions of the current item. Users who shoudl receive permissions can be extracted from different sources - current user, author, last editor, user inputed in the item fields or by user when launching the action. There are many options and ways you can use this activity in. If you have some comments or ideas, please write them in comments to this post.

Second hotfix for 1.4 - updated

Today we have released a hotfix for version 1.4.

The hotfix fixes 2 things:
  • It will contain full French version, with all literals translated
  • It will fix the error causing the action conditions to ignore the functions (thus you cannot use any functions in the action conditions)
You can download the hotfix from here

Friday, September 11, 2009

Workbox technical videos

We have strated to publish our technical videos on the You Tube.

These videos will help you to understand how different Workbox functionalities work and how to use them.

Our You Tube channel is On the right side of the blog you can find the newest videos. We are planning to release the core of the technical videos by the end of next week.

Thursday, September 10, 2009

Permission reporting tool for SharePoint

Few days ago Microsoft has released the Fourth Release of the Microsoft SharePoint Administration Toolkit. It was announced on the SharePoint team blog.

A very interesting part of this toolkit is a permission reporting tool. I think that every administrator should have it on their MOSS/WSS environment as this helps with permission management on the farm. It is also really useful when working with Workbox - it can help you debug some problems with the permissions to the workflow and workflow items.

Generally the tool allows administrators to quickly check users' permissions. This is very useful, since due to multiple inheritances and big number of permission levels it is very easy to lose track who has which permissions.

The tool allows you to check on every level - site, list and even item - what permissions has chosen user. The tool displays what kind of permission levels given user has to a chosen object and how were they assigned (through group or directly). More about this functionality is here.

Reporting tool gives you also ability to quickly glance through permissions for all lists and sites in a given site. It also lets you to compare the permissions to parent permission and list which are different - who was added and who was removed. More on

What is strange - the tool does not tell you that a user is a farm admin.

The third cool thing is a broken inheritance report. This report gives you information what are the permissions for current object and its siblings. More info about these report is here. The reports are in form of an XML, but can be easily opened in Excel. By default reports are stored in SharePoint list. It takes some time to run the report.

You can download the tool from here.
Here are some tips about the setup:
  • you need to have SP2 with the April Cumulative Updates. I would recommend installing the June Updates, as the April ones are included in the June CU. All details how to setup the June CU are here. Make sure you install SP to all the language packs, as without them you will not be able to install the CU.
  • after you setup the Toolkit you will find the reporting tool in the folder where the toolkit was setup (by default C:\Program Files\Microsoft\SPAdministrationToolkit\PermissionReportingSolution). It's in the form of a WSP. You need to use the STADM and addsolution operation and to set it up on your farm. Here is an MSDN article on how to add solution, depoly it and activate the feature from the STSADM 
  • Next you need to deploy the solution from the central administration (operations -> global configuration -> solution management).
  • The last step is the feature activation - you activate it for the farm. You need the April CU to activate the future.
After that you are good to go. Enjoy!

Tuesday, August 18, 2009

Hotfix for 1.4

Today we have released a hot fix for version 1.4. The latest version is Please download it from here:

The hotfix fixes these 3 errors:
Sorry for problems these errors might have caused.

Thursday, August 13, 2009

Action launch form

 Currently in Workbox you can ask users to provide some information when they launch an action. This is a very simple mechanism, which is lacking a lot of features - you just chose the variables and that's all - no control over validation, default value or text on the launch page.

This has been a big pain for us for a long time, but with every release other things seemed more important. Finally in this release we have chosen the modification of action launch form as our top priority.

How will this functionality look? We wanted to keep the very simple and intuitive way of choosing the variables and give you at the same time a lot of configuration capabilities.

We have come up with the following - the "variables" window on the action properties will change to "Launch form". The existing form will be heavily modified and will look something like this (sorry for Polish screens but I don't have time to translate them):

On this window (going from the top):
  • do not show the form and launch action without confirmation - after choosing this button rest of this window will be inactive and when user clicks on the action launch button or selects it from the context menu action will launch immediately
  • Copy the form's settings from different action - you can select another action in this workflow and copy the settings to this action
  • Form header - a text field which allows you to input DHTML that will be displayed as a header of the page. You can use lookups to make the content rich with information
  • Variable picker - this picker works a little like user picker in the role membership. It has replaced the checkboxes on the old "action variables" window. This picker allows you to choose which variables will be used as form fields. You can also change their order on the form and enter field properties window.
  • Manage variables button - open variables window - this is the same button an in the old window
  • Form footer - same as the header but is displayed below fields and above the buttons.
This screen does not bring much new into the form management - the new thing is that it allows you to enter form footer and header, control field order and see better which variables are chosen.

The real power is in the field properties. This window works much like list columns setting on SharePoint. We were trying to keep it as similar as possible, so it would be straightforward to SharePoint users. Also the launch form itself will be in SharePoint design, so users will see the interface they know. We will also use the standard SharePoint controls for the rich text box, people picker etc.

The window will look like this:

There are 3 groups of parameters:
  1. General properties. This group has 3 fields:

    • name
    • description
    • field type- will have the following values - single line of text, multiple lines of text, number, date and time, yes/no, list, people picker, file.
      By default name will have the name of the variable, description will have the description of the variable and field type will be by default the type of the variable. We will introduce lookups to variable name and description.

  2. Validation - here you will be able to set validation rules. These fields will change depending on the field type.
  3. Properties - here you will be able to set default value (you can use lookups for that, by default the value of the variable will be set here), source of the dropdown list, etc.
Most of the fields work like this - when you select the variable, all default values will be set to the field. User is presented the form and inputs the values. Values are then stored within the variable. Because you can use lookups in most of the fields, it is really easy to display all the data user needs to launch the action - for example you can insert a link to the item or display a value from the item as a default value of some field.

In the release after the next one you will be able to create a dropdown list that provides the values from different lists from the entire SharePoint application, filter these values, add additional ones, etc. Something like this cross site lookup but more powerful.

The file field works a bit different. First - it gives you the ability to upload many files at once - without having to reload the window like on SharePoint form. Second - files are not stored within the variable. Instead of that, you can define where the files uploaded by user should be stored. They can be stored as files in the document library or as attachment to a chosen list item.

Wednesday, August 12, 2009

Plans for the next release

Sorry for the late post - we have started working on the release and I couldn't find the time to write on this blog.

The new release - probably version 1.4.5 will introduce 2 big features - saving workflows in STP and action launch form management.

This means that starting from the new release you will be able to save your site as a site definition and then create a new site from this definition. All your workflows saved in the definition will match and deploy automatically.

In the new release, instead of just choosing the variables for the action launch form, you will be able to completely control the form - more details in next post.

Also in the new release:
  • values provided on the action launch form will be displayed in the history
  • you will be able to specify the folder in the item activities
  • Workbox will be setup as a site and not site collection feature - this will give the administrators more flexibility in configuring their environment
  • Action launch URL lookup - you will be able to get the URL of the action launch pages for the next state. Thanks to that you can for ex. send an e-mail with a link that takes you to the "Accept" action page, instead of just to element.
  • "IF", "And", "Or" functions
  • History for the "If" activity
and as always - bug fixes and more "Help"

Wednesday, June 17, 2009

Different models of approval workflows - voting approval

In the previous posts I have described the first answer applies workflow and multi-approval/multi-reject workflow.

In this scenario a number of rejection votes or approval votes are needed to approve or reject the item. For example – 3 approvals are needed for the item to be approved and 2 rejections are needed for the item to be rejected.  
Note that when setting up this kind of scenario you need to make sure that the voting algorithm will not cause a clinch where item cannot be accepted nor rejected. If you have 6 or more users, then 3 approvals or 2 rejections model is fine. If you have less than 6 users, then in some situations workflow could end in dead point. 
To create a workflow that will meet this scenario:
  1. Create a role "Approvers" and add selected users (you can assign users, domain groups or SharePoint groups). You can also add users later on with the activity "Add to role".
  2. Create a state "Waiting for approval".
  3. Add four actions – two named "Approve" and two named "Reject". One “Approve” and one “Reject” action must lead back to the “Waiting for approval” state (we are creating a loop). The other pair can lead to where you want, for example to the ending state.
  4. Assign the "Approvers" role to all “Approve” and “Reject” actions.
  5. Create 2 variables – “Approved votes” and “Rejected votes” – set both to “integer” type.
  6. In the looping actions add “Add to role” activity. Use it to add the “Current user” (use lookups to go to SharePoint -> Current -> Current user) to “Denied” members of the “Approvers” role. Note: use activity clipboard to copy the activity.
  7. In the looping “Approve” action use the “Set variable” activity to set the “Approved votes” variable to “Approved votes”+1.
  8. In the looping “Reject” action use the “Set variable” activity to set the “Rejected votes” variable to “Rejected votes”+1.
  9. In the non-looping actions add “Approve/reject item” activity and set it to approve/reject the current item.
  10. In the looping “Approve” action set action launch conditions to “Approved votes < 2”.
  11. In the looping “Reject” action set action launch conditions to “Rejected votes < 1”.
  12. In the non-looping “Approve” action set action launch conditions to “Approved votes >= 2”.
  13. In the non-looping “Reject” action set action launch conditions to “Rejected votes >= 1”.
What's going to happen in the workflow:
  1. Workflow enters the "Waiting for approval" state
  2. Members of "Approvers" role have 2 looping actions "Approve" and "Reject" – both “Approved votes” and “Rejected votes” variables are smaller than 2.
  3. Until two people chose “Reject” or “Approve” only the looping actions are available
  4. Every time the looping action is launched, a vote counter is raised by one and the workflow is entering the “Waiting for approval state”
  5. If 2 people have approved, then the looping “Approve” action will disappear and the other “Approve” action will be visible. This way the third approval action will be the one doing the final approval.
  6. If someone has already rejected, then the looping “Reject” action will disappear and the other “Reject” action will be visible. This way the second rejection action will be the one doing the final rejection.
  7. When the non-looping action is launched, workflow exits the "Waiting for approval" state and item approval status is set to “approved” or “rejected”.

Tuesday, June 16, 2009

Different models of approval workflows - one approval, one rejection

In this post I will continue the previous post about different approval workflow models. There I showed how to create a "First response applies" workflow.

2) One approval 
In this scenario we need only one approval to approve an item, but to reject it we need all approvers to reject. This means if anyone approves - the item is approved. But the item is rejected only after the last person from the approvers rejects the item. 

Download the workflow definition
See a screencast on how the workflow is defined.

To create a workflow that will meet this scenario:
  1. Create a role "Approvers" and add selected users (you have to use NAMED users, do not use domain groups or SharePoint groups, later on you will see why). You can also add users later on with the activity "Add to role".
  2. Create a state "Waiting for approval".
  3. Add three actions "Approve", "Reject" and “Final rejection”. “Approve” and “Final rejection” can lead to where you want, for example to the ending state. “Reject” action must lead back to the “Waiting for approval” state (we are creating a loop).
  4. Assign the "Approvers" role to “Approve” and “Reject” actions. Remove permissions for everyone from “Final rejection”.
  5. In the “Reject” action add “Remove from role” activity. Use it to remove the “Current user” (use lookups to go to SharePoint -> Current -> Current user) from the “Approvers” role.
  6. In the “Approve” action add “Approve/reject item” activity and set it to approve the current item.
  7. Copy the activity to clipboard
  8. Open the “Final rejection” action and drag the activity from the clipboard. Change approval status to “Reject”
  9. Open the “Waiting for approval” status and click “Self-timer” button.
  10. Set self-timer to launch the “Final rejection” action 0 minutes after workflow enters this state. In the conditions set that the “Allow” membership of the “Approvers” role must be empty. Note: if you are using a workaround, the membership must be equal to “empty”.
What's going to happen in the workflow:
  1. Workflow enters the "Waiting for approval" state
  2. Members of "Approvers" role have 2 actions "Approve" and "Reject". “Final reject” is not visible, as they do not have permissions to launch it.
  3. If anyone from the approvers launches the action “Approve”, workflow exits the "Waiting for approval" state and item approval status is set to “approved”.
  4. If someone from the approvers launches the action “Reject”, then this person is removed from the “Approvers” and cannot launch any actions anymore. Workflow returns to the “Waiting for approval state”.
  5. Every time the “Reject” action is launched, workflow is entering the “Waiting for approval state” and self-timer condition is checked.
  6. If the person doing the rejection was the last approver in the role (everyone else already has rejected), then the role membership is empty. Self-timer condition is met, so the self-timer action will be launched. This is why you need to use named users – otherwise you would not be able to check if all members of a group have already rejected. Note that because timer is launched by SharePoint job action “Final rejection” will not be launched momentarily – it can take up to 5 minutes.
  7. “Final rejection” action is launched, workflow exits the "Waiting for approval" state and item approval status is set to “rejected”.
 3) All must approve 
In this scenario we everyone to approve the item. One rejection is causing the item to be rejected. This means if anyone rejects - the item is rejected. But the item is approved only after the last person from the approvers approves the item.

As you can see this scenario is exactly the same as the “One approval” – only the “Reject” and “Approve” are switched. Switch “Approve” and “Reject” action names, change “Final rejection” name to “Final approval” and change the activities between “Reject” (previously “Approve”) and “Final approval”.

Next post (voting approval)

Different models of approval workflows - First response applies

We have received a number of questions regarding different approval models. Workbox does not offer any predefined workflow models, but allows you to create a workflow that completely suits your needs. We have defined some sample approval workflows that might help you get an idea how to define your own approval workflow.

In this and following posts I will focus on 4 most common ones:
  1. First response applies
  2. One approval (2nd post)
  3. All must approve (2nd post)
  4. Vote (3rd post)
Below I will show you how to implement each of these scenarios on any list.

For every scenario there is a workflow definition file for you to download and use. It will help you understand how the workflow is configured.

I have used a list with content approval turned on, to give you the idea when item is accepted or rejected. In the final approving or rejecting action I have used “approve/reject item” activity. This is just an example of what you can do in the approval actions and it is not required for the workflow to work properly. 

1) First response applies 
This scenario is really simple - decision of the first approver counts. This means if anyone approves - the item is approved. If anyone rejects - the item is rejected. 

Download the workflow definition
In this scenario all you have to do is:
  1. Create a role "Approvers" and add selected users (you can use users, domain groups or SharePoint groups). You can also add users later on with the activity "Add to role".
  2. Create a state "Waiting for approval".
  3. Add two actions "Approve" and "Reject", that lead to where you want, for example to the ending state.
  4. Assign the "Approvers" role to both actions.
  5. In the “Approve” action add “Approve/reject item” activity and set it to approve the current item.
  6. Copy the activity to clipboard.
  7. Open the “Reject” action and drag the activity from the clipboard. Change approval status to “Reject”
What's going to happen:
  1. Workflow enters the "Waiting for approval" state
  2. Members of "Approvers" role have 2 actions "Approve" and "Reject"
  3. After anyone from the approvers launches the action, workflow exits the "Waiting for approval" state and item approval status is set to either approved or rejected.
Next post (one approval, all must approve)

Wednesday, April 8, 2009

Workbox vs other workflow solutions

We have received a number of questions regarding how Workbox places itself against other Workflow solutions on the market, like Nintex, K2, Skelta or Kaldeera.

First of all, Workbox is working on the state workflows, all other products use sequential ones. In our opinion the sequential workflows are harder to use when modeling a complex processes and also are harder to comprehend. People tend to think more in a state workflow manner - "what is happening with the invoice now", "what is the current situation", "what I want to do next with this item". If you have a large workflow seeing (like in sequential workflow) all actions on one diagram is very confusing and does not give you a general insight of the process.

Also, we are much more integrated with SharePoint – we use SharePoint's engine, lists, users, permissions and so on, so the environment is easier to deploy, manage and develop. Users do not have to use additional add-ins like special workflow libraries or separate sites and tasks list to use the workflow. They can act directly from their item - invoice, task, call.

Next thing – we only have the web designer, so all functionality is available through the web. Other companies (except Kaldeera) have additional windows applications, that provide the full functionality, and the web designer is less functional.

We also think, that our designer is easier to use and provides more capabilities in some areas like lookups. Lookups in Workbox are very powerful and give users the ability to use the SharePoint and external application data in the workflow.

Workbox is a small but powerful solution. We have heard many times that people see other workflow solutions as huge tools where they are not sure where to start from, how to configure it, how to install it and how to do more complicated things. We try to keep the designer simple, limit the number of objects and just enhance the way you can configure the objects and make them work together. At the same time Workbox is very flexible. You do not have a predefined solution that you must use (for example an approval activity) and adjust jour process to the tool's capabilities. It takes a bit more configuration but gives a lot more flexibility and allows you to model the process exactly as you want it to run.

We are at the same time aware, that we lack certain things our competitors have – like reporting. We are just starting with workbox, and with every release we are making it more and more functional. We think that our state workflow architecture and deep integration with SharePoint give us great advantage over other products. And also we are cheaper than the competition products and our licensing model is more flexible.

Wednesday, January 14, 2009

Workbox team

This is the team that creates Workbox:


project sponsor, Workbox inventor

CEO of Datapolis. Has came up with the idea of Workbox and for the last 2 years is defining the general direction Workbox is moving in.


project manager

Project manager of the Workbox project and key analyst. Makes sure Workbox is usable and that new releases keep coming.

Also runs this blog.

He's an MCTS in configuring WSS and MOSS and MCP in MSF and analyzing application requirements. Also an expert in SharePoint area on experts exchange.


dev team leader

An experienced developer and system architect.
Responsible for solution architecture and server part of Workbox.


main silverlight dev

Silverlight expert, MCTS in application development for MOSS.
Responsible for the core designer functionalities.



Our special task force. If it's impossible, she will find out how to make it work. Responsible for the visual SharePoint part of Workbox and the designer forms.


key tester

Makes sure Workbox is released without errors. He's a real pain for all developers.


graphical designer

Makes sure Workbox is pretty and functional.

These people left the Workbox team, but added a lot to the project:
DAMIAN DUDEK (left the team in June 2009)


DAWID IRENO (left the team in Feb 2009)