Short and Sweet

imageAs I indicated earlier in the year, I am doing less of the heavy lifting around our SharePoint space lately. I think I mentioned that this would have an impact on this blog, and well, I think that starts today. I’m not planning to stop or to go to a less frequent editorial schedule but I do have less to say.

I’ll wait for the applause to stop.

Seriously, I can wait.

OK, here’s the first short and sweet SharePoint Story.

One of the things I’ve been doing lately is helping a young woman build a site to store, track and display the results of our upcoming Wellness Contest. I say helping her build, because she is doing all the work. I’m looking over her virtual shoulder (via Lync) but she is navigating the browser, creating the lists and libraries and she is constructing the SharePoint Designer workflows. My contribution is a lot of:

oh, I see why that didn’t work” and “ok, now go back into the browser and try that workflow again…

So far, the most memorable moment for me is when she was terminating a workflow gone haywire and, looking at the workflow results page, said:

These error messages don’t really tell you much do they?

No, no they don’t – Welcome to SharePoint.

This post is about two bits of my personal style that I felt were important enough to pass onto her, and I’m going to refer to one that I’ve already mentioned. Let’s get the reuse out of the way first.

As I said a few weeks ago, I like building multiple small workflows instead of single large ugly workflows. Yes, adding the word “ugly” is a literary technique to skew your opinion toward agreement with mine. I don’t want you to think I’m trying to subtly manipulate you – the manipulation attempt is blatant.

I had a new reason for sharing this technique today though. Having short, single-purpose workflows helps a person build their reference library. Everybody forgets how to do some of the wonderful things they did in an earlier moment of greatness. It’s nice to be able to say “oh, I remember doing that when we did the Wellness contest back in 2014” and to be able to open that workflow and study it. If you open a workflow that scrolls on for several pages, you’ll likely be too confused to gain much benefit.

By the way, in addition to reusing the old thing, that counts as one of my two new things, so I’m almost done.

The second new thing has to do with clarity. Simply put, use more variables. For instance, in the workflow we were working with today, we are processing a step count that arrives by email. If there is an error, we are going to send an email back to the person who sent in the steps. That bit of information is in the Current Item From field, and we could reference it from there. However, I’d rather store it to a variable called “vFrom” and then send the error message to ‘vFrom’ if / when we have to. When we look at that workflow, the variables are visible, readable and the workflow makes a certain amount of sense.

When she finishes this project, I’ll provide a full description here; maybe I’ll even be able to coax her into writing that post. Until then, maybe I’ll actually do some work of my own, or I’ll offer up another short and sweet observation.

Divide and Conquer

imageWhen I was making the coffee table that sits in my office, I learned a lot about bending steel. Specifically, I learned that bending square steel tubing isn’t easy and often doesn’t end well. Some bends were wide enough that I could negotiate the turn and repair the damage, but others were just a bend too far. For those, I took it in steps: cut, bend a little, cut again and then weld back together. I thought about that process this week, as I struggled with a workflow issue. I’m not sure if this is a common issue, but it seems to come up for us quite often:

“Is it better to build one big, ugly, complicated workflow or is it better to create a few additional lists and spread the work across them?”

We almost always tend to spread the complexity around. In the solution I’m working on today. I need to accomplish three major steps in order to reduce a 12-15 page Word document into a series of entries in a custom list:

  • Parse all of the recommendations out of the Word document
  • Determine if the recommendations are New, Open, Pending or Closed as of the date of this report, and
  • Create entries into either a custom list of recommendations or in a custom list of updates to existing recommendations.

All of this can be done by a workflow, but it’s a complicated task. A single big ugly workflow would need to keep track of individual recommendations, whether they are new or some other status and look up the details about the inspection report metadata and copy it into the other lists. I opted for a process that involves two additional custom lists:

One is a list of what I call “splits.” Splits are the big chunks of parsed text. All the new recommendations are in a split. Likewise, all the pending recommendations are in a split, and so on. A workflow that runs when the splits are created doesn’t have to determine what kind of recommendation it’s dealing with, they are all new, or pending, or some other status.

That workflow parses all the recommendations into individual entries in the second list. That list is then built up of individual recommendations which have a status (new, pending, etc.) and all the metadata that they need to be transformed into an item in the ultimate destination list. A final workflow that runs as these items are created takes care of dispatching those items.

The cost of this solution is the creation of a couple additional custom lists and a bit of duplication of data (although the items in these intermediate lists can safely be deleted). The benefits include:

Easier to plan – The overall process is easier to plan and stage. The process becomes a fairly simple routing exercise. Big boxes of the same thing arrive at one list where they are opened, separated and distributed to a second list. It’s like a wholesale-to-retail operation.

Easier to build the workflows – Rather than a complicated workflow with lots of variables and lots of steps, I have three single-purpose workflows that are each of a manageable size. I built the process in discreet steps, only moving forward once things are working at each level.

Easier to control new vs. update action – By the time I need to know whether to create a new recommendation or an update to an existing recommendation, the list item I am working with includes that information as well as everything I need to create those items.

Easier to debug – This is a big deal for the developer (me). As I am configuring these workflows, there’s really only one way any of them can fail. That is so much easier to deal with than a workflow that can fail any of three or more ways, especially given the current state of SharePoint Designer’s debugging tools.

Easier to rerun – Some of the workflows trigger alerts, some set metadata in other lists and change the status of other processes. Working in smaller segments means there are fewer things to fix if something ultimately goes off the rails.

It might be tempting to just keep on grinding out steps in a single workflow. However, dividing the steps into logical groups and taking advantage of storing partially processed items in interim lists is a very powerful concept. This approach makes design and development easier. By the way, it worked for that coffee table too. If you want to read more about that project, take a look over here.

I Didn’t Know That

clip_image002Next up in my series of summer shorts is an interesting lesson learned while completing a “tiny” SharePoint Designer workflow. This started over on my AIIM blog where I was explaining how I was fixing a contact list that had been built backwards. Instead of setting all the contact and address components, people were simply entering a mailing address in complete form. That approach works well for preparing a label, but not so well for writing the letter, unless you like starting out by saying “Dear customer” or “Hey you.”

Fixing the contact list was supposed to be an easy task. A guy on my team wrote a small program to snag the address block and bust it into all the little address components. We pasted those into the contact list (after adding back in the missing component columns) and to keep the mailing label users happy, a short workflow would reassemble the multi-line column continent. In addition, I was demonstrating SharePoint and SharePoint Designer to a woman who will be a pinch-hitter on our team. Of course, this is SharePoint so everything didn’t go according to plan, but that’s a learning experience too. Below is a quick summary of the things we learned along the way:

Microsoft is in Washington – I used to live in Seattle, and there are people on the left coast who are surprised by the fact that Zip codes in the northeast begin with zero. When we parsed the composite addresses into components, we saved them as a CSV file. When I double-clicked to open that file, 06033, the Zip code string for our office turned into 6033, the number. Pasting that into SharePoint failed because the column was looking for text.

There’s an interesting twist to this. If you open Excel first, you can tweak the text settings and then import the CSV. That works well for the zip codes, but we discovered a different problem. The multi-line text fields export from SharePoint well, and import nicely if you double-click the CSV file. If you open the CSV file as an import target, expect a few problems with the multi-line fields. Fortunately, we don’t need the multi-line fields, but we are researching this for the day that we do, but I digress.

String Builder is a Tease – Building a composite string from component text variables is pretty easy in String Builder. For example, you can type:

     [City], [State] [Zip]

which will result in a single line, with comma and nicely spaced. You can also type:

     [Address line 1]
     [Address line 2]
     [Address line 3]
     [Address line 4]

which will also result in a (rather unreadable) single line string.

No problem, Google and all the wonderful members of the SharePoint community came to the rescue. There were a couple of solutions offered for adding line breaks to multi-line text but the one I liked was simply adding the html break <br/> at the end of the line. There’s an interesting and understandable twist to this too – this only works if the multi-line text column is configured for Rich Text. That compounds the earlier twist, because the import problem doesn’t affect plain-text multi-line columns, only rich text.

I Can’t Run This Workflow on Every Item in the List – Actually, I can but only after applying a little client-side script magic. If you want to learn how to do that, jump over to the king of how-to-make-SharePoint-do-the-hard-stuff blogs and read one of Marc Anderson’s SharePoint Services Stories (clever name) – actually, it’s the very first SharePoint Services Story. Marc’s blog is my go-to resource, and his solution is elegant and reliable, but I didn’t really need it today. As you may recall, I already had the composite columns. I just had to make sure that those fields would get created and updated when new entries are created and old entries are changed – I think that’s called testing.

In case you’re wondering, we wrapped each of those address line thingies in an If-statement so we didn’t end up with blank lines.

Have a great weekend!

SharePoint FM

clip_image002I spent my freshman year at the University of Georgia (go Bulldogs) and thanks to some friends on my dorm floor, I was able to visit some beautiful parts of that state. Once while driving around some desolate south-Georgia back roads, we stumbled across a Pirate game on the radio. I recognized KDKA AM 1020 Pittsburgh immediately by the announcer’s voice. We could hear that game in Georgia due to the ability for AM radio waves to skip across the planet, bouncing off the Ionosphere. FM radio waves, due to the different way they propagate, are limited to line-of-site reception. Hmm, if this is an analogy to SharePoint, wouldn’t I want to be AM? No; we chose an FM model because it’s more narrowly focused, but capable of delivering a higher quality signal (think classical music vs. political talking heads). If we extend this analogy just a little closer to the breaking point, we like operating in a narrow band of the “development spectrum” within SharePoint so we can:

Focus on Quality – This is very important to my team. We don’t want to simply be a company that uses SharePoint; we want to implement Content Management in SharePoint. That requires adherence to the standards and best practices associated with ECM, not just the creation of a bunch of libraries. In addition, we want to improve the business process associated with the creation, use and distribution of the information that we store in SharePoint. In the current project that I’m working on, I have worked with the owner of the process to build a better way of entering data, segregating data and presenting data for review. In the course of defining the requirements, we are expanding the use case from one where we keep track of stuff to one where we keep track, manage, analyze and share this stuff with our coworkers and our customers.

Stay close to home – We keep our solutions close to “out-of-the-box”, because we want our users to be able to understand, combine, extend and reuse the work we’ve done. We also don’t want to invest too heavily in development because we have better things to be developing. No offense to ECM, but out-of-the-box SharePoint can look pretty good, and if it’s easy to use and satisfies the customers, we don’t need to make it overly snazzy. Plus, I keep coming back to the notion that, in using SharePoint, people learn how to use SharePoint, and that knowledge is cumulative. I have also found that my coworkers are more interested in how the solution works, than appearance. I think there’s a fine line between adding functionality to have the page look tricked out and modern, and adding functionality that improves the user experience – we’re working hard to find, but not cross that line.

Be a wee bit anal – I know that some of you might be asking “why not just let your users develop their own solutions from the ground up?” The answer is simple and a bit selfish; I don’t want to join some friends of mine who have been left with half-finished or half-baked SharePoint solutions when some department level guru decides to leave. I want our solutions to be documented. I want to know what needs to change if we move the solution to a new server, or to our Internet-facing farm, and I want to be able to maintain the “systems” that our employees have come to rely upon. I also want our solutions to follow some standards. For example, where we have managed metadata in use, I don’t want to see a solution that is using a Choice column that has (at the moment) the same information as what is in the term store.

The system that I mentioned above organizes data from a series of inspection reports and follow-up meetings in three related lists. In order to review that data, we built a Web Part Page that contains about 5 Data View Web Parts to pull the related bits from those lists and present them in a useful format. To setup the page, we pass a bunch of parameters in with the URL. For example, based on source parameters, the page can be grouped by Facility, or by Engineer, or by Category. We construct those URLs in a workflow and store them with each item in the master list so they can be exposed as links in a wide variety of views. The Facility link, for example will configure the page to be grouped by Facility. We could have just built a second DVWP page to drive the sort and filter process and then build the URL on-the-fly, but that would put us in maintenance mode. SharePoint Views look pretty good, and many of our users can build them. Letting them add the URLs to their own views, lets them extend our solution. It’s still a line-of-sight system, but it has a little better reach.