Promoting InfoPath columns to SharePoint is typically a very straightforward task. You go through InfoPath’s publishing wizard, select the InfoPath fields you’d like to promote, and you’re ready to go.
But what if you need to publish a value to a Person field that is defined in SharePoint? Maybe you need to build a workflow that uses the person’s information, or just want to see the person’s presence in the form library. Or, in the case of what I experienced, you needed to create views that filtered this InfoPath field by the person that was currently logged in. Try using the [Me] filter on a non-Person field in SharePoint…it doesn’t work.
A Person field is a field who’s type is that of “Person or Group”, and it allows you to select SharePoint users from the people picker. For this example, I’m going to create a Supervisor column in my SharePoint list, so that I can promote my InfoPath field to it:
In theory, you should be able to just go through InfoPath’s publishing wizard and select your column to promote. If you don’t already have a column defined, it will create one for you in the list, and if you just go through the publishing wizard, it’ll create a “Single line of text” column for you. Since we already have a column defined, specifically the Supervisor column which is of type Person, we need to select this from the wizard. A lesser known feature in InfoPath is the ability to map an InfoPath field to an existing column in the list, or even a site column defined on the site or site collection:
From the “Site column group” drop-down list, select "(This document library)”, which will then allow you to select a column that has already been defined in the list. Choose Supervisor and click OK. Oops! You get a nasty error message:
As it turns out, you cannot promote a text field to a Person field in SharePoint. I even tried to finagle the Contact Selector, and trying to promote its data, and I get the same result. Here’s a little workaround to this issue:
Step 1: Create the Person field in SharePoint.
Step 2: Promote the InfoPath field to an additional column
For this example, I’m promoting my supervisor field to the SupervisorHidden column. Notice that I chose to create a new column in this library as opposed to selecting an existing column:
Step 3: Create a simple SharePoint Designer workflow to copy values
Create a workflow in SPD, and make sure you choose to fire the workflow every time the item changes. Next, select the “Set Field in Current Item” action. Set the Supervisor column to the SupervisorHidden column in our list. Finish the workflow.
Step 4: Create a new form
Once you create a form and save it to the form library, the workflow will fire and the value that was promoted to the SupervisorHidden column will be copied into the Supervisor Person field. Simply hide the SupervisorHidden and the workflow columns from your views, and you’re all set!
For the most part, any workflow we build will involve participants that have access to the respective site, and won’t involve external users, or users that don’t have permission to the site. A client pointed out a blurb in a TechNet article that mentioned you can allow non-authenticated users to participate in a workflow, and I had never heard of that, so of course I had to find out what it was all about.
MSDN mentions that by enabling this option, you can allow either or both of the following types of non-authenticated users to participate in workflows: internal users who do not have access to the site and external users who do not have access to any internal network resources. For internal users, an email message is sent that explains how to request access to the site (subject to administrator approval). For external users, an email message is sent with an attached document or list item for the participant to review or sign.
To test this, I first enabled the setting in Central Administration. Navigate to the Application Management tab, Workflow Management, then Workflow settings. Check the Yes radio button to enable external users to participate:
Next, let’s use a document library, and add a simple out-of-the-box approval workflow that is configured to route to an external address. For this example I’m using a document library named External Documents, and have added an instance of the Approval workflow named External Workflow. For the approvers, I’m adding an external email address to test with:
Whenever a new item is added to the library and the workflow gets kicked off, an approval email is sent to the external email address that was specified in the Approvers field that includes the document as an attachment. What I don’t particularly like is the email still includes the link to the actual document, and if you hover over it, you can see the full URL to it. The whole purpose of this is to send a copy of the document because the recipient doesn’t have access. Why include a link if they’re definitely not going to have access to it?
Now, from here the workflow is disconnected. Obviously because the external users don’t have access to the site, they can’t complete tasks, navigate to the document library, etc. It us up to the external user to review the document and contact the initiator.
In addition to the email that is sent to the external email address, a email is sent to the initiator of the workflow indicating that the external user doesn’t have access to the item, and a task has been created for the initiator to be completed whenever the external has responded:
This isn’t limited to document libraries either – the same rules apply to list items. The only difference is instead of the document being sent as an email attachment, you get to see the fields directly in the email:
And that’s it! Even external users and users that do not have permissions can participate in workflows!
Lately I have been answering a number of questions related to workflows, specifically what you can and can't do with SharePoint Designer (SPD), and what advantages a custom Visual Studio workflow has over one created in SPD. Basically, there are 3 ways to implement a workflow for SharePoint: use an out-of-the-box workflow, build a custom one using SharePoint Designer, or build a custom one from scratch using Visual Studio. 99.9% of the time, we eliminate the first option right away, as our clients rarely need something as simple as what the included workflows provide. The following is a description of what's possible with the other 2 options, and how to make the right decision for which one to use.
SharePoint Designer
SharePoint Designer is obviously the preferred choice for creating workflows that need to do basic things, such as sequential document approvals, sending emails, creating tasks, etc. The workflow designer wizard is user-friendly and easy to use, and attaching a workflow to a list or library is a cinch. However, if you need to do something that's not given to you in the wizard, you don't really have much of an option other than to fire up Visual Studio and develop something custom. Let's take a look at some of the things SPD can't do...
#1. [Lack of] Reusability
The most frequently mentioned limitation of SPD workflows is the inability to reuse them. These workflows are bound to a list and site at design time through the workflow designer wizard, which does not offer the ability to publish to multiple locations. This can potentially be overcome with manually copying the source files and updating the list and field ID's in the XML manually as described here, but this is extremely error-prone and not always effective. I've seen cases where the source files were copied manually, the ID's were updated, the workflow republished, and the workflow still did not fire. I didn't spend a significant amount of time troubleshooting it, just be aware that this is not a supported method of reusing workflows, and may not always work.
#2. Limited Conditions and Actions
With SPD you're basically limited to what is provided with the workflow designer wizard. You're given a handful of conditions and a handful of actions, and that's what you have to work with if you're unwilling to write any code. The included conditions and actions are simple and straight-forward and do not offer any customizations. Some of things that one might think SPD is capable of doing out-of-the-box, but can't:
- Accessing Active Directory information directly, such as manager name or email
- Kick off another workflow
- Remove or grant permissions on the list item
- Remove or grant permissions on a list, library, or site
- Copy/move list items to a list in another site
- Send emails with attachments
- Jump to, or return to, another step in the workflow
- Access information or content of the actual document in a document or form library -- SPD can only see the list columns.
- Create or delete lists, libraries, sites
- Wait for an item to change for a maximum amount of time
#3. No State-Machine Workflow Support
Workflows usually fall into one of two categories: sequential and state machine. A sequential workflow is one that runs through all the steps and actions in sequence, one after another. This may include parallel activities, where a bunch of people receive an email at once, for example, but the workflow as a whole runs from start to finish. A state machine workflow represents a set of states, transitions, and actions. One state is denoted as the start state, and then, based on an event, a transition can be made to another state. The state machine would have a final state that determines the end of the workflow. A state machine workflow is typically used when a particular step in a workflow needs to be repeated, such as during an approval process. Take for instance the following scenario I encountered at a client:
A form to approve a product was created and submitted to a SharePoint form library. This form when initially submitted needed to be routed to the requestor's manager. The manager has the option to approve it and forward it on to the pricing manager, or reject it and send it back to the requestor, in which case that portion of the workflow would start over again, and would follow the same approval process. If approved and sent to the pricing manager, this person would have the option to approve the form, send it back to the requestor, send it back to the manager, or send it back to both parties. Yyyyeah...SPD can't do that. There isn't a handy "Jump to Workflow Step" action. The solution that was provided to the client was to handle a lot of the logic in the InfoPath form itself which used a decent amount of managed code in the form itself for some of this. All SPD was used for was to send emails.
In conclusion, if the workflow requires steps to be repeated, look elsewhere other than SPD. If you're using an InfoPath form, you may be able to throw in enough logic there to do what you need, and if not a Visual Studio workflow may need to be explored.
#4. Limited User Data Collection
SPD provides a Collect Data From a User action that allows will create a task in the Task List and allow you to provided fields for the user to provide simple information. For example, a single line of text, a checkbox, a drop-down list with pre-defined values, etc. This creates an associated ASPX with custom SharePoint controls and logic, and cannot easily be modified. In addition, you can't code the ASPX page to do anything custom in conjunction with the workflow, such as provide a drop-down list populated with SQL data, then use that elsewhere in the workflow. Once again, you're limited to what you're given here. A similar SPD action is Assign a To-Do Item, where you're able to specify some text which will create a task for a person and use the value you specify as the Task title.
What's nice about a Visual Studio workflow is you are able to assign a custom task form to a task, which can be used to collect data. This can be an InfoPath form or a custom ASPX form, and can contain custom code and logic, and the usual InfoPath and ASP.NET controls, respectively. You can do whatever logic and data presentation you need to do, and are not restricted to what's provided out-of-the-box with SPD.
#5. Task/Action Dependencies
Another item not often thought of is the dependence of a task to the action that actually needs taken. For example, a task can be created that says "Review this form and update some value", but how does the task know when it's completed? If you bypass the task completely and go to the form and update the values and save it, the task will have no idea that the form has been updated. Likewise, if you just complete the task without actually doing anything, it doesn't ensure that you did what you're supposed to do.
Since you control every step of the workflow in a custom VS workflow, you can enforce this dependency. Do not provide complete buttons on your task forms, and leave it up to the running workflow to check the status of the submitted form and update the associated task accordingly.
These are just a few of the main points that continuously come up when designing workflows, and assessing whether or not SPD is the right tool. Luckily, we haven't had many requests to provide the aforementioned functionality, so we've been able to make SPD jump through enough hoops to provide what they've needed.
When to Use SharePoint Designer
So, when is it a good idea to use SPD? The answer is all of the time unless you absolutely can't. If you can do it in SPD cleanly (key word being cleanly), then I recommend you do. You won't find an easier way to create a simple task, send an email, or associate the workflow to a list, and you shouldn't recreate the wheel if the functionality is provided for you already. If you need to do one of the items described above, or if you find yourself creating many individual workflows for the same "workflow", or if something you need to do can only be done using custom code, then consider writing a custom SPD activity or creating a workflow in Visual Studio. Read on to find out if these other options are the right choices.
Custom SharePoint Designer Workflow Activities
As already mentioned, SPD gives you a handful of conditions and actions ("activities") out-of-the-box. There are a ton of actions that I think should be included, but aren't. Luckily, a framework is in place that allows developers to design their own SPD workflow activities, deploy them to a server, and have them be accessible to all workflows created in SPD.
Through a little bit of coding, configuration, and deployment, you are able to build your own activity that will appear in the SPD workflow designer wizard as an action. This is plenty useful if you foresee a need to provide missing functionality to variety of workflows, such as an Active Directory lookup, or the ability to create sites or lists on the fly within a workflow. Custom activities should only be considered when #1. the functionality isn't already included as an SPD action, and #2. the custom activity can be used for more than one workflow. Custom activities are deployed globally, so it's not a good idea to create one specific to a single workflow, because there's nothing stopping other users of SPD from using it on one of their workflows, potentially screwing something up or doing something unintended.
Limitations of Custom SharePoint Designer Activities
While you can do almost anything with .NET code (and custom activities are written in .NET), you're still bound to the limitations imposed by the SPD workflow design process. You still can't write an action to jump to a particular step in the workflow, you still can't have the workflow run as another user (you can run your custom activity as another user, however), you still can't move SPD-authored workflows around easily, etc. You can do whatever you want for that particular action in that particular step of the workflow, but you're still constrained to using the SPD workflow designer.
When to Use Custom SharePoint Designer Activities
Custom activities are a nice middle-ground between what you're given with SPD by default, and building a workflow from scratch using Visual Studio, but keep in mind they serve a very specific purpose: to provide common functionality to all workflows. Since they're available in the wizard, they are able to be used in any workflow. If you haven't picked up the point yet, do not create a custom action that shouldn't be used by more than one workflow!
Useful SharePoint Designer Custom Workflow Activities
Luckily, other developers have seen the light when it comes to custom activities, and have built a few useful ones to address some of the missing functionality described above. The following activities can be downloaded here:
- Send Email with HTTP Attachment
- Send Email with List Item Attachments
- Start Another Workflow
- Grant Permission on Item
- Delete List Item Permission Assignment
- Reset List Permissions Inheritance
- Is User a Member of a SharePoint Group
- Is Role Assigned to User
- Lookup User Info
- Copy List Item Extended Activity
- Send Email Extended
Visual Studio Workflows
All workflows used in SharePoint rely on Windows Workflow Foundation (WWF), which is a piece of .NET goodness introduced in version 3.0. Whether it's an out-of-the-box workflow, or SPD-authored workflow, they're all powered using this technology. The difference with those 2 options versus creating one yourself in Visual Studio is most of the leg work and overhead is already done for you. With Visual Studio it's up to you, the developer, to code every single thing that needs to happen during the workflow. It's important to note that by creating a custom workflow in Visual Studio, it's not going outside the bounds of an appropriate workflow-creation tool -- Visual Studio is just another tool to use to create SharePoint workflows, and a very powerful one at that.
What's wonderful about a workflow created from scratch is you're given all the power to decide what you want the workflow to do. You're not bound to certain conditions or certain activities like you are with SPD. In addition, some workflows (like a state-machine workflow) aren't even possible in SPD, so Visual Studio must be used.
Visual Studio workflows also enable you to use custom forms at certain points in the workflow. A custom InfoPath form or ASPX page can be written to display or collect any information that you want, and have that integrated into the workflow. For example, if you need to collect information or provide user-configurable options when assigning a workflow to a list, you can develop an association form that collects this data. If you need to collect information when the workflow is kicked off for a particular item, you can implement an initialization form. You can even collect information during the workflow using custom task forms. For workflows that need a significant amount of user-provided data during the workflow in order to make decisions inside that workflow, Visual Studio will probably need to be leveraged to provide a custom form for that data collection.
Finally, Visual Workflows are reusable and moveable. They're implemented as SharePoint Features, and only need installed and activated on whatever SharePoint environment you're using. You assign the workflow to a list at runtime, not design time like you do with SPD. You can use the same workflow on 100 different lists if you need to. In SPD, you would have to recreate that same workflow 100 times, or make 100 copies of the workflow in order to achieve this.
Drawbacks of Visual Studio Workflows
Obviously the drawback to building a custom workflow in Visual Studio is the time it takes to do so. With the out-of-the-box and SPD-authored workflows, so much of the initial overhead is done for you, and it's easy to take that for granted. It's up to you to decide exactly what is supposed to happen, how to get the data from the list item as needed, and make the decisions in the workflow. Visual Studio uses a number of activities that help facilitate this, but it is a time-consuming and cumbersome process.
Another drawback is implied from the first: only developers have the ability to create these workflows. An advantage of an SPD workflow is that business users are [usually] smart enough to create them, and don't need to contact IT or a developer to do it for them (yes, I know what I just said, but that's the intended use of SPD...)
When to Use Visual Studio Workflows
The default answer for this is....use a Visual Studio workflow when you can't do something with an out-of-the-box workflow or with SPD. If you need to implement a state-machine workflow, or you need to collect a lot of complex information from a user during the workflow, or you need to reuse a workflow over and over again, etc., then you should build it in Visual Studio.
This next answer should have as much weight as the previous...build a Visual Studio workflow if it will result in a better-architected, cleaner solution. It may very well be possible to accomplish something using a combination of SPD workflows and a handful of custom actions, but rarely is that good design. By having multiple moving parts, you're introducing multiple points of failure that each have to be maintained. It is better to force a good solution than to force a particular tool on a client.
So, How Do I Choose?
Great question! The answer is easy -- do the simplest thing possible that will result in a clean solution. If you can implement the requirements with an out-of-the-box workflow, use that. If you can implement the workflow in SPD using the included conditions and activities, use that. If you can use SPD for all but one tiny thing that could be addressed by a reusable activity, build one and use SPD. And if you can't provide the requirements in a clean, maintainable solution using SPD, then build it in Visual Studio.