Notes SharePoint Blog

Steve Walch's blog about his favorite migration tool and other things related to Lotus Notes migration projects

Category Archives: Workflow

Migrating Notes workflows that implement “dynamic” document security

2 Comments Posted by on February 4, 2011

We have discussed various issues about workflow in the past [link].  To make a long story short, there is no way to press a button and magically translate Notes code-based workflows to SharePoint declarative workflows, but Notes Migrator for SharePoint does an excellent job at migrating your workflow state. 

Recently we have been getting a few questions about how people should handle workflows that automatically change the security of the document as it moves through various workflow stages.  For example, imagine a Notes application that lets an “Author” add or update travel requests until they are ready to submit it.  Once the request is submitted, however, the Author can no longer make changes and it us up to her “Manager” to approve it, reject it, or make further changes.  Real-world Notes applications can easily have many such dynamic access rules.

The way Notes developers typically implemented this type of workflow was was to have buttons, formulas and agents that implemented the right steps.  The actual security rules were usually implemented using reader / writer fields that listed specific people (or groups) that were currently allowed to update the document.  So when the Author pressed the “Submit to Manager” button, some code would run which looked up the manager and updated the reader / writer fields on that document so that now only the manager could edit it.

(Side note, there are also some cases where people did the security enforcement in the user interface.  That is to say, they tried to hide the parts people were not allowed to see in the UI.  But most Notes developers understood that this was not true security.)

So when we migrate this document, we have the option to map those reader / writer fields over to the equivalent document-level permissions in SharePoint.  Notes Migrator for SharePoint makes this trivial.  But it is important to remember that the security on this document is really just a snapshot of its current workflow state.  A workflow process on the SharePoint side is going to need to pick up the document from there. 

In the SharePoint world, you will really have two choices.   If you are using something like InfoPath to design complex forms, it will be possible (though not necessarily a good idea) to implement the workflow the old way:  with code on your form buttons and other form events.  It is possible that you could write code that set the appropriate document level permissions as described above. 

It is more likely however that you will want to switch to declarative workflow instead.  Declarative workflow means that you have a workflow engine interpreting a set up rules that someone (not necessarily a developer) has configured.  This could be a built-in SharePoint workflow, something designed in SharePoint Designer, or something designed in Visual Studio.  Another great choice is to implement the workflow with an add-in tool such as Nintex.  Regardless, your workflow definition will include rules to update the document level permissions according to your business rules.

The workflow capabilities in SharePoint Designer get stronger with each new release.  For example, SharePoint 2010 now has explicit actions for Adding, Removing, or Replacing the permissions on a list/library Item.  This is one more example of something powerful you can do in SharePoint 2010 without writing code!

image

Note that you will not see these particular actions in the standard drop-down action list; you will only see them if you are inserting actions into an “Impersonation Step”.

SharePoint 2010, Tech Notes, Workflow

Cool stuff in SharePoint 2010 that Notes customers will love: Declarative Workflow

1 Comment Posted by on February 3, 2011

When people think of complex custom Notes applications they think of workflow.  Workflow is an especially important consideration when migrating Notes applications because migration tools, which can do a great job migrating schema, content, security and forms, have a hard time translating Notes workflows to SharePoint workflows.

Notes workflows are almost always implemented as code attached to various buttons, form events, and agents.  By contrast, the Microsoft platform encourages you to use declarative workflows where you express your workflow as a set of rules that can be entered, modified, and (best of all) understood by a non-programmer.  You can write code if you need to, but this code is usually confined to “activities”, the units of action that you wire together in your declarative workflow.

Declarative workflow capabilities have improved significantly in SharePoint 2010.  First of all, you get a much richer set of out-of-the-box workflows that you can use in your applications.  This list depends on what edition of SharePoint you install and which SharePoint template you are using, but at a minimum it should include an Approval Process, a Collect Feedback review process, a Collect Signatures review process, and a Disposition Approval workflow for managing content lifecycles.  You can now customize the out-of-the-box workflows if needed or design your own from scratch.

image

If you do need to design your own workflows, you can benefit from the new capabilities in SharePoint Designer.  This was a somewhat limited option in SharePoint 2007, forcing many companies to use Visual Studio instead, but those days are gone.  Now SharePoint Designer workflows can address the need of the majority of the workflows found in Notes applications without have to write code.

Users have a much bigger vocabulary of workflow “conditions” and “actions” to choose from, including Notes-like things such as changing the permissions on a document after it is submitted for approval, sending mail notifications, looking up a person’s manager, and moving content to another location.  A particularly powerful feature is to impersonate other users during a workflow so it can perform certain actions using the workflow author’s credentials.  You can even use InfoPath to design nicer forms for collecting information from end users.

image image

You can now design workflows that operate at the site level or the list level and you can reuse workflows across an entire site collection and even export them to use on a completely different SharePoint farm.  Workflows can be visualized as a set of human readable steps and even exported to Visio for graphical display.

The takeaway here is twofold.  First you can replace most of your Notes workflows without writing code.  Save your expensive developers for the hard stuff.  Second, do not attempt to translate all the code that your Notes developers wrote into code on the Microsoft platform.  Instead, devote your energies toward understanding what your old workflows did and make sure you have a deep understanding of how to accomplish these same things in a declarative workflow world.

SharePoint 2010, Workflow

Migrating workflow state and approval processes

Leave a Comment Posted by on February 1, 2011

As described previously, when migrating Notes workflows to SharePoint workflows you are really switching from code-based workflows (logic encoded in button events, agents, etc.) to declarative workflows.  And using Notes Migrator for SharePoint, you can migrate your workflow state so you can preserve in-progress workflows between the two systems. 

To achieve this, simply migrate the  (status fields, next review, due date, whatever) as data columns in your list items, InfoPath documents, Word documents, etc.  Depending on how you designed your workflow, you may be done at that point, or you may need to customize it.  The relevant part is that when the workflow starts up for newly written list items,  it should be designed to examine these columns and “advance” to the right state.  For example, the out-of-box “three state workflow” does this but others may not. 

A special (but very important case) is when you are able to replace your “approval process” workflows with SharePoint’s built-in approval process.  This can be a huge win for reducing development costs and eliminating the need to maintain the application later.  What used to be a custom developed application can be replaced with a checkbox feature! 

image

Of course, Notes Migrator for SharePoint correctly migrates the state for that as well.  The relevant part of our documentation can be easy to miss, so I will repeat it here:

Advanced: Customizing SharePoint Data Target Definitions
…
The Type property can be set to any of the available field types:
…
• Approval Code – Sets the approval status of documents that are migrated to SharePoint. Input data must be one of the following strings: “Approved”, “Denied”, “Draft”, “Pending”, “Scheduled”.

In other words, map some piece of data (probably using a formula) that yields the values “Approved”, “Denied”, “Draft”, “Pending” or “Scheduled” to a Target field of type “Approval Code”.

There is a lab on this on our support site:  https://support.quest.com/SUPPORT/index?page=solution&id=SOL52223  (Lab 4.5).

Notes Migration Projects, Notes Migrator for SharePoint, Tech Notes, Workflow

Basic approaches to migrating Notes workflows to SharePoint

Leave a Comment Posted by on December 22, 2010

As our customer base gets smarter and smarter about SharePoint and migration issues, I hear about Workflow more and more.  It was amazing how often it came up at the SharePoint Conference compared to other shows 6, 12, 18 months ago.  

Naturally, all of our customers would like to push a button in our tool and migrate their Notes workflow applications to SharePoint.

The core problem is that Notes people typically implement “workflow” by writing hundreds of lines of formula or LotusScript code on button events and agents.  Even though people have been using Notes to do workflow for years, there is actually no specific workflow feature in Notes.  In SharePoint, declarative workflow is an actual feature and is implemented completely differently.  The RIGHT thing to do to rethink how workflow should be done in SharePoint.  SharePoint has a range of options from out-of-the box workflows, to SharePoint Designer workflows, to workflows build with Visual Studio and custom .NET code (C# or VB.NET).  This is on top of the built-in “checkbox” features such as the document approval, versioning, and check-in check-out features available in SharePoint lists and libraries.  So in many common cases, those 100 (or 1000) lines of LotusScript can be replaced by a simple code free SharePoint construct.

I have made the above explanation to partners and customers many times over the years and have come to realize that they need more than an excuse (even if it is a really good excuse) for why out tool does not attempt to map apples to oranges.  They need some practical advice.  So I have started a project to explore how I would go about migrating typical Notes workflows to SharePoint.  I want to be able to deliver a strong set of specific advice as to how we recommend customers approach the problem and all the things that Quest tools do do to help.

This is still an evolving area, but here is a rough outline:

1. Notes Migrator for SharePoint does a great job at migrating the data (and metadata) that is used to drive the workflow process in Notes (for example the “Next Approver” and “Status” fields).  This can be made to work well with most SharePoint workflow processes.   Our tool writes the data record, including the workflow state, and the SharePoint workflows are triggered automatically.  A subsequent post will cover this in more detail.

2. We are working with vendors of high-end Workflow products such as Nintex to better understand how how our tools should be used together.  Our customers already use our products together, but I think we can help them by providing better samples and prescriptive guidance.

3. Quest’s Web Parts for SharePoint (an awesome tool in general for quickly building complex user interfaces, like the ones you have in Notes, on SharePoint) has a lot of support for working with SharePoint workflows and third-party workflow products.

4. The Notes Migrator for SharePoint Analysis tools make it easier to understand which applications receive mail, contain lots of agents, etc.  As these tools evolve, they will get better at helping you understand more fully what that old Notes “workflow” really did.

Quest’s system integrator (SI) partners are already great at helping customers navigate this complex terrain.  Quest will continue to improve its tools, samples and guidance but meanwhile I encourage customers to bring in the right services people to help. 

PS:  There are some people who will tell you that complex workflow applications can’t really fit on SharePoint and you should therefore invest in rebuilding them as expensive Visual Studio based solutions.  I suggest escorting that person out of your office.

Workflow

Follow

Get every new post delivered to your Inbox.