Creating a Document Set with SharePoint Designer 2013 Workflow

Synopsis: This post describes the challenges with creating a document set via a SharePoint 2013 workflow.

My client needed the ability to fill out a form, then trigger a workflow for various approvals. As approvers went through various process, then needed a place to collect documents. A document set made sense here and it only made sense that the workflow create the document set.

So I set off researching how to do this. I found a good article by Ann Stenberg on technet which walked through this process for 2010. It exactly what I needed. In the workflow section, you can see that it simply creates a new document set by creating a new list item. And that made sense because it was really a folder, sort of, which was itself an item.

Now that I understood this, I first created a new document set following the instructions here manually. I manually created a document set from the new item menu and that worked fine. It provides a nice landing page for the document set too. Fine.

(By the way, as you see above I used my own content type which simply inherited from Document Set called Sample Document Set)

Next, I went on to create a site workflow (based on SharePoint 2013) in SharePoint Designer to prove this out. I added a create item action and specified the following:

Content Type ID:	Document Set
Path and Name (*):	234 *

* This was just some arbitrary value that was to represent my form ID eventually. It would become my document set name/folder.

I manually ran the workflow in the browser. It worked, but I didn’t get what I wanted. I got a plain old folder instead. Not what was supposed to happen. Thanks SharePoint. And there was no friendly welcome page that the other manually-created document sets have.

After looking at this with SharePoint Manager it was the right content type, but it was just a folder to the user. Everything was exactly as the other items.

By the way, SP Manager 2013 Online is a great tool to have if you’re doing cloud development.

As it turns out there are properties on the folders that are important. Drilling up to the folders in the site, you’ll see the issue. The SharePoint 2013 workflow action/activity for creating a new item is different than 2010.

 

The work around…

Since this works in SharePoint 2010 workflows, the solution is to build a SharePoint 2010 workflow that does this and call it from the SharePoint 2013 workflow. Thankfully, the new workflow engine can initiate 2010 workflows. The way I did this was to create a 2010 site workflow in SharePoint Designer first. That performs the work of creating the document set properly.

When choosing the site workflow, I chose 2010 as the workflow engine.

When editing the workflow, I created an initiation parameter so I could pass the name of the document set (in this case I called it document set ID).

If you were to run this workflow by itself, you would see this parameter in the UI for you to type in before the workflow starts. We’ll call this workflow from another workflow, so we’ll just pass it as a parameter.

Next I created a new item in the host document set library – this is the library that has the appropriate doc set content attached to it. I changed the content type and used the workflow initiation parameter for the name of the document set (I also used a “Request ID” field in my custom content type):

The 2010 workflow looks like this. The new item ID is returned in a variable, which you can use or ignore:

Next, I created a list-based workflow using the 2013 workflow engine. This workflow calls the 2010 workflow. See below for the entire workflow:

The highlighted line above shows how we are starting a separate workflow. When run, we pass in “202” as the name of our document set. The parameter dialog for the workflow shows how our 2013 workflow wires up values to the initiation of the 2010 workflow (or any other workflow for that matter).

Again, here we are passing DocSetID, but that’s really just the name of the document set. It produces the results we wanted too.

This is a pretty neat thing to know as far as reusability goes. There’s a draw-back here in that we’re depending on the 2010 workflow engine. So future versions of SharePoint may have issues with this, but this is a decent work-around for now.

Debugging Workflows In SharePoint 2013 Online using Azure

This is just so cool… You’re now able to debug workflows in SharePoint 2013 online by using your Azure account. Just this past weekend we (Composable Systems) hosted the Azure bootcamp here in Louisville, KY and I gave a dev talk on Service Bus. As it turns out, you can use one of your service bus namespaces to help you develop SharePoint 2013 workflows as well as remote events. Very timely indeed.

I’m building a SharePoint 2013 App for our largest client, Microsoft. This one is specifically for the Bing division, which they’ll use internally. I’m using Visual Studio 2013, SharePoint Online through our Office 365 subscription and a SharePoint App template. We’ll eventually deploy this to their internal SharePoint App store.

The first thing you need to do is go into the Azure portal and create a namespace under the Service Bus category, or choose an existing one you’ve already created. I just created a new one. No other configuration was needed here.

Once the namespace is setup, you’ll need to copy the connection string from the connection settings button near the bottom of the screen.

I just copied the ACS connection string.

Next, open the SharePoint App project properties in Visual Studio.

Now that is setup, I can do a couple of things. I can write details out to the console and I can set breakpoints. Wait… write to the console? Yep. When you press play to deploy/run your app, VS.NET starts a console that listens to that Service Bus.

So in this case, I added a WriteLine activity to my workflow (this comes from the Primitives section of the toolbox).

This will show up in my console when running the app. Here’s what that looks like.

And the breakpoint experience is really neat. When it breaks, you can explore all your local variables. Very handy.

The Future of InfoPath Forms

Probably one of the most important topics to Composable Systems, and myself personally, at the SharePoint Conference (2014) is the future of InfoPath Forms. InfoPath is supposedly gone as a product… That means in about 10 years, we’ll have to deal with migrating our forms to some other tool or set of tools.

Relax. That’s 10 years. InfoPath is going to be supported in its current form and will still be part of the next version(s) of SharePoint. Forms hosted in SharePoint will still work. The app will work on the desktop as well. So we’ll have time to migrate to a new solution, but we shouldn’t wait too long to re-think our forms. Having said all that, the future is still not too clear. At the SharePoint Conference today, Microsoft said that they’re very much in flux here and are looking for help from the community to guide this. They said there’s a lot of work going on here within Microsoft, but there’s nothing ready to ship anytime soon. So there was no big announcement. It’s not what I wanted to hear, but at least they’re transparent in their position here.

Despite this, the team gave a good classification of the different types of options/tools available to deal with this. Here are the items they covered. Some things are available today, others are coming in the future.

Excel Surveys

This has already shipped with SharePoint. It’s often overlooked and most people haven’t even heard of this. This is actually a great solution for simple surveys and forms. There is a simple designer to add as many questions, of varying type, to the form. These simply become columns in Excel. And you get to share the survey URL for people to fill out. When results come in, they go directly to the spreadsheet – and in real-time. To create one, just choose new “Excel Survey” from within a document library.

List Forms

This is new stuff. It wasn’t really a product announcement as in replacing InfoPath, but it did put a nicer experience on top of a list. These are MS Access-based forms that sit on top of a list. Before we go too far here, this is just the form part of MS Access and is entirely web-based. It’s based on HTML5 and is initiated using the ribbon while editing a list – there is a new “design form” button that sits right next to the InfoPath button. It’s a fast and flexible design surface which allows drag/drop support of labels and fields. You can re-size and re-position. It’s just form elements for the current list though. You essentially create a new view. It’s not as comprehensive as I would have hoped. This will ship in SharePoint online within the next 3-6 months.

Structured Documents

This is another scenario where Word documents are used as high-fidelity documents which gives users a more WYSIWYG experience. These are fillable word documents where the form fields can be edited and/or filled out. It meets the need of an online as well as offline scenario. These most closely resemble the InfoPath forms, but are not nearly as complex. They’re just for filling out and capturing data. Also, the data is kept in the Word document, so it makes for a good archival story. This functionality is about a year off.

App Forms

These are the most complex forms. These are based on MS Access online which allows for a relational and fully transactional database behind the scenes. By the way, the new MS Access online databases are based on SQL Azure. So it’s going to be scalable, capable and reliable. This is currently shipping in the online version.

So, this is sort of like the Shuttle program being shut down without a real clear path to get to the space station. Not what I wanted to hear – I really wanted a cool HTML5 based application that did what InfoPath did, but without all the strings attached. I guess we’ll wait and see on this – we’ll keep you up to date on this. We’ll also deal with this on a case-by-case basis. Sometimes using InfoPath, sometimes creating our own HTML5 forms.

Odd Error When Retrieving Items from an SPView

When attempting to retrieve items from an SPView programmatically, you cannot reference fields by name or by their ID.  Note, I’m using MOSS 2007 with SP2.  So here’s the code that causes the issue (and resulted in over 3 hours of wasted time)…

Guid listId = new Guid(...);
Guid viewId = new Guid(...);

SPList list = SPContext.Current.Web.Lists[listId];
SPView view = list.Views[viewId];

SPListItemCollection filteredItems = list.GetItems(view);

foreach (SPListItem item in filteredItems)
{
    Response.Write(item["Title"]);  // THIS FAILS
}

And you’ll see this error:

Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Value does not fall within the expected range. at Microsoft.SharePoint.SPFieldMap.GetColumnNumber(String strFieldName) at Microsoft.SharePoint.SPListItemCollection.GetRawValue(String fieldname, Int32 iIndex) …

Thankfully, the SPView object exposes a Query property which is a string that contains the CAML that filters list items.  Using this property, you can just create your own SPQuery object and retrieve the items from the list.  The following code has this modification.

Guid listId = new Guid(...);
Guid viewId = new Guid(...);

SPList list = SPContext.Current.Web.Lists[listId];
SPView view = list.Views[viewId];

SPQuery query = new SPQuery();
query.Query = view.Query;      // GET THE QUERY PROPERTY FROM THE VIEW

SPListItemCollection filteredItems = list.GetItems(query);

foreach (SPListItem item in filteredItems)
{
    Response.Write(item["Title"]);
}

Hopefully, this saves you some time.

Document Library Icons Missing

Here’s something to keep in mind as you provision document libraries inside SharePoint.  You can provision document libraries through both the web (site) and site (site collection) scoped features.  The way you would do this is through use of the ListInstance element similar to the following:

<ListInstance
  Id="Expenses" Title="Expenses" OnQuickLaunch="False" RootWebOnly="true"
  FeatureId="00BFEA71-E717-4E80-AA17-D0C71B360101"
  Description="Contains expense documents."
  TemplateType="101" Url="Expenses">
</ListInstance>

Unfortunately, when provisioning document library instances from site collection features the icons appear to be missing.  In the object model, which you can’t change after the fact, the ImageUrl property is empty.  If you look at the “View all site content” link, you’ll see what I’m talking about.

This is just something to be aware of.  It may not be a show-stopper, but it’s an inconvenience to your users.  I’d recommend provisioning your lists as site features (at the Web scope).  It may mean more features to manage, however.

Keep Site Definition IDs Unique

This recently bit me.  I had two different site definitions.  They had two different webtemp xml files, of course.

Here’s the first one:

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="STORESITEDEF" ID="10010">

...

The second looked like this

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="MARKETSITEDEF" ID="10010">

...

When I went to create my site, I kept getting this error:

The template you have chosen is invalid or cannot be found...

I incorrectly assumed that the ID was only relevant within a given site definition – why this wasn’t a GUID, I don’t know.  Anyway, I changed one of my IDs to be different and after an IISRESET all is well.

Always Capitalize (all-caps) Boolean Values in CAML

So here I was, late at night, banging my head against the desk trying to figure out why my a custom field’s custom property wasn’t hiding when I clearly stated Hidden=”true”.  As it turns out, you need to specify the uppercase value for that boolean or it simply won’t work.  There’s no error; it just doesn’t hide.  Here’s a snippet of code where this bit me while developing a custom column using the ProperySchema section to allow additional settings to be used for the field.

<FieldTypes>
  <FieldType>
    <Field Name="TypeName">CustomColumn</Field>
    <Field Name="ParentType">Note</Field>
    <Field Name="TypeDisplayName">My Custom Column</Field>
    <Field Name="TypeShortDescription">My Custom Column</Field>
    <Field Name="UserCreatable">TRUE</Field>
    <Field Name="ShowOnListCreate">TRUE</Field>
    <Field Name="ShowOnSurveyCreate">TRUE</Field>
    <Field Name="ShowOnDocumentLibraryCreate">TRUE</Field>
    <Field Name="ShowOnColumnTemplateCreate">FALSE</Field>
    <Field Name="FieldTypeClass">ACME.SharePoint.Blah.CustomField, 
       ACME.SharePoint.Columns, Version=1.0.0...</Field>
    <PropertySchema>
      <Fields>
        <Field Name="MySetting"
               Hidden="TRUE"
               DisplayName="My Setting:"
               MaxLength="500"
               DisplaySize="40"
               Type="Text">
          <Default></Default>
        </Field>

   ...

As you can see Hidden is set to “TRUE.”  “true” simply does not work.

What’s funny is that the WSS.XSD gives you intellisense in VS.NET (in most areas) for the following options for boolean fields: true, false, True, False, TRUE, FALSE.  Ok.  Why?

This was just one case where my choice of case caused an issue.  What about everywhere else?  So proceeded to tell my colleagues, including Bryan Phillips, about this oddity with hiding properties of custom fields.  He said that he always uses uppercase.  Not only for custom columns, but for everything.  I’ve typically used lowercase since it seemed to be close to my c# practices.  However, from now on, I’m going to capitalize my boolean values.