• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM

Hi all

Welcome to another exploration of the collaborative world through a lens called the facets of collaboration. If you are joining us for the first time, I am writing a series of posts that looks at how our perception of collaboration influences our penchant for certain collaborative tools and approaches. SharePoint, given that it is touted as a collaboration platform, inevitably results in consultants never being able to give a straight answer. This is because SharePoint is so feature-rich (and as a result caveat-rich), that there are always fifty different ways a situation can be approached. Add the fact that many clients do not necessarily know what they want and learn about their problem by examining potential solutions, we have all the hallmarks of a wicked problem in the making.

These wicked problems, underpinning SharePoint, often results in Robot Barbie situations (cue the image to the left), which is the metaphor that I started this series with. Robot Barbie represents everything wrong about SharePoint deployments, as it is symptomatic of throwing features at a platitude, pretending to be solving a real problem and then wondering why the result doesn’t gel at all. It is a pattern of behaviour that is similar to an observation made by the very wise (and profane) Ted Dziuba who once spoke these words of wisdom.

If there’s one thing all engineers love to do, it’s create APIs. It’s so awesome because you can draw on a white board and feel like you put in a good day’s work, despite having solved no real, actual problems. Web 2.0 engineers, in addition to their intrinsic love of APIs, have a real hard-on for anything having to do with a social network. For example, developing a Facebook application lets them call their shitty little PHP program an "application" running on a "platform," like a real, live computer programmer does. Make-believe time is so much fun, even for adults.

Apart from making me giggle, Dziuba may have a point. Elsewhere on this blog I have spent time explaining that there are different types of problems that require different approaches to solving them (wicked vs. tame). My conjecture is that collaboration itself is exactly the same in this regard. People who espouse a particular type of tool or approach as the utopian solution to collaboration are taking a one size fits all approach to a multifaceted area and even worse, treating that area as a platitude. Anyone who calls themselves an Information Architect and doesn’t at least give cursory examination to the dimensions or facets of collaboration is likely to be doing their stakeholders a disservice.

All of us have certain biases, and I am no exception. For a start, I am generation X – the so-called cynical generation. Apparently we whinge and whine about everything and then blame it all on generation-Y. Thus, if cynicism is the gen-X stereotype, then I will happily accept being the poster child. I mean seriously, all of you vanity obsessed, self interested generation y’ers, if you spend a little less time preening and more time thinking, we might get some wisdom out of you (see – I am such a cynical gen-X right now).

So let’s recap the facets of collaboration. The model I came up with identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the last post, I used the model to examine the notion of Business Process Management versus Human Process Management and looked at some of the claims and counter claims made by proponents of each. This time let’s up the ante and talk about something curlier. We will examine the notion that social networking in the enterprise is the answer to improving collaboration within the enterprise. On first thought, it makes perfect sense, given the incredible success of Facebook, LinkedIn and Twitter. Nevertheless, there is ongoing debate about the use and value of social tools in the enterprise driven by their rise outside of organisational contexts. One particularly strongly worded quote is from Aaron Fulkerson, co-founder and CEO of MindTouch who doesn’t mince his words:

This class of software forces business users to adopt the myopic social visions imagined by the developers, which are nearly identical to their corresponding consumer web implementations. In short, social software is not solving business problems. In fact, these applications only serve to treat symptoms of the problems businesses face. They exacerbate the real problems within businesses by creating distractions and, worse, proliferate more disconnected data and application silos.

Ouch! Even within the SharePoint community there is significant variation of opinions as to the value of social. While I better protect the innocent and not name names, I have spoken with several well known SharePointers who think social is a giant waste of time, versus those who see real value in it. Irrespective of your opinion, you cannot ignore the fact that social is a significant game changer with effects still being felt. While web 2.0 has dropped off the Gartner hype cycle, its effect on particular sectors has been far reaching. Now it seems that all sectors have a 2.0 on the end of their name. For example:

• Enterprise 2.0
• Education 2.0
• Legal 2.0
• Government 2.0

Clearly, if things were just a flash in the pan, why are governments around the world trying to revitalise their public sector by utilising these tools?

Look at Microsoft as another example. They have, I think smartly, recognised industry trends and reacted to them via the introduction of a number of new SharePoint features, such as tagging/folksonomy via managed metadata, ratings columns, enhanced wiki capabilities and a significant investment in the capabilities of my-sites. Their clients now have the option to leverage these features should they choose to do so.

So just as there are naysayers, there are the pundits. Many people cite the reasoning that these features are necessary to attract and retain the next generation of workers, who have grown up with these tools in their personal lives. Whether this claim is valid is debatable, but I have to say, I really like the Enterprise 2.0 slide deck below by Scott Gavin for a number of reasons. I think it encapsulates the 2.0 vision, underpinned by social/cloud technologies very nicely. I sometimes ask people to discuss this slide deck in my IA classes and discussion is equally polarising as social networking in the enterprise itself. Some people think it represents the vision for the future, and others think it is hopelessly idealistic and doesn’t reflect cold, hard reality. Take a look for yourself below…

And the survey says…

Using the facets quadrants, we can start to see patterns for success of these tools for the enterprise and whether Aaron Fulkerson’s argument has merit or whether Scott Gavin is on the right track. An interesting use of the facet diagram is to plot where various tools and technologies are located. in my classes, I ask people to plot where Facebook belongs on facets diagram. Guess where it is usually drawn? 

While some people will draw Facebook at various levels on the vertical axis, everyone pretty much describes Facebook (and LinkedIn)  as trait based, while being highly dominant on the social quadrant. As discussed in the last article, if I ask people to plot a crowdsourced tool like Wikipedia, the dominant characteristic is always trait/social. In other words, people maintain and update Wikipedia articles because of their interest in the topic area, not because it helps them get something done.

Clearly, big social networking technologies are successful in the "trait based social” quadrant. In other words, we tend to use Facebook more for common interest collaboration than to solve a task based collaborative issue (such as deliver a project). Another interesting thing about a lot of social networking technologies is that for many, our work-based collaborative life tends to be more task based, compared to our non-work which is more trait based. In other words, for a lot of us, our work life revolves around working with a group of people for a common outcome and if it was not for that common outcome, we wouldn’t necessarily have much in common (I risk falling victim to my own generalisation here – so I will come back to this later in the section titled “Why User Buy-In Is Hard”).

When you look at where Facebook sits in the quadrant, it begs the question of how well this type of tool (or the building blocks it is based on) would work in an organisation that is project (task) based and highly transactional. To that end, consider a project management information system, such as the basic one that Dux espouses in his book or the more complex one that Microsoft sell to organisations. Where do you think it belongs on the quadrant?

When I ask people to plot their project management information system, I typically get this response:

I speculate that the further away two tools lie on the spectrum, the more likely we are to have a robot-barbie solution if you blindly mix features that work well in each individual quadrant. The wiki argument I made in part 3 seems to support this contention. If you recall, in part 3 of this series, I mentioned that I ask every attendee of my classes if they had ever seen a successful project management wiki.  Irrespective of the location of the class, the answer was pretty much “no”. I noted that where I had seen successful wikis tended to be where the users of the wiki were linked by strong traits.

Looking Deeper

While that is interesting, I think the facets diagram tells you more than it intends. Obviously, it is clear that these project management systems such as MS Project Server are oriented toward task/transactional (“getting things done”) aspect of project delivery (ie, time, cost, scope, budget and the like). While some people might point to this and say “there you go – I told you all that social crap was a waste of time – bloody gen-Y and their social networking hubris”, I feel this is naive. If task based transactional tools are sufficient, then why do so many projects fail?

I have stated many times on this blog that shared commitment to a course of action requires shared understanding of the problem at hand. The act of aligning a team to project goals and developing this shared understanding is the realm of the task/social quadrant (the top left), where insights and outcomes come together. When I ask people to name tools that live in this space, few can name anything. Obviously, most project management systems are devoid here. Worst still, we subsequently delude ourselves to thinking that shared understanding can come from a few platitudinal paragraphs labelled as a “problem statement”.

Social networking pundits implicitly recognise this issue (and frequently butt heads against command and control type project managers as a result). But i feel they make the mistake in applying a one size fits all approach to collaboration and apply trait based tools as a panacea when they are not wholly appropriate. The social tools seem to fit exceptionally well into the top right quadrant, but not in the top left.

In fact the only tools that spring to mind that belong in the top left category are the sensemaking tools that my company practice, such as Dialogue Mapping.

Where’s the proof, Paul?

So I guess I am arguing that using social tools because they are the “choice of the new generation” ignores a few home truths about the nature of these tools versus the nature of organisational life. Just because Microsoft provide the tools for you, tells you that they are hedging their bets rather than having any more insight than you or me. So to test all of this, let’s use the facets model in a different way to back up some of my observations and suggestions in this post. Guess what happens when I ask people to plot SharePoint itself on the facets map?

When I asked SharePoint practitioners to do this, they initially drew SharePoint 2007 as a circle over the entire model. Once they did so, they would very often adjust the drawing to emphasise transactional over social collaboration as shown below.

When practitioners were asked to draw SharePoint 2010, they usually indicated a higher representation in in the two social quadrants, but favoured the trait based social over task based social as shown below.

What was interesting about this experiment is that very few people drew SharePoint over the entire facets of collaboration. Social collaboration with SharePoint it seems, only stretches so far. This leads me onto more conjecture, and now we get to the bit in the post where we name a giant SharePoint elephant in the room.

Structured tools for social collaboration?

Many collaborative tools purport themselves as operating in the social space. SharePoint 2010 clearly does so, principally due to the Managed Metadata service, pimped MySites with tagging/rating capabilities. But SharePoint’s core heritage is database/metadata driven, document based collaboration. If we go back to our definition of social collaboration as dynamic, unstructured, with sharing of perspectives and insight through pattern sensing, then social collaboration is clearly not a predefined interaction.

Yet, database driven tools like SharePoint, and its building blocks like site columns and content types require considerable up-front planning to install and govern. Many, many inputs need to be well defined and furthermore, unless you have learnt through living the pain of things like content type definitions in declarative CAML, SharePoint buildings blocks are difficult to maintain/change over time. SharePoint suffers from a problem of reduced resiliency over time in that the more you customise it to suit your ends, the less flexible it gets. In the case of social collaboration the problem is worse because we are trying design for outputs where the inputs are not controlled. Trying to turn something that is inherently organic and emergent to something that has an X and Y on it may be misfocused and destined to fail in many circumstances. The realm of well-defined inputs is the realm of transactional collaboration, where workflow and business process management thrive and change is much more controlled before SharePoint ever gets a look in.

SharePoint excels at transactional scenarios as this is its heritage – after all, the majority of its feature set is oriented to transactional collaboration. The fact that people are prepared to draw SharePoint as dominating across across the transactional half of the facets diagram illustrates this.

But this raises interesting, if not slightly heretical question. If we need to use information architects to get a collaborative tool deployed for social collaboration (to get those inputs defined), then are we pushing the solution into the transactional side of the fence? Recall that in part 3 of this series, I looked at document collaboration and noted that when asked to draw team based document collaboration, people typically drew it operating in the social half of the matrix (pasted below for reference). I also noted in part 3 that for team based collaboration, rules and process are much less rigid or formalised with regards to document use and structure. I then referred to a recent NothingbutSharePoint article where a large organisation’s attempts to introduce the usage of content types largely failed. Like the seeming lack of success of wiki’s for task based collaboration, maybe content types simply are not the ideal construct as you move up the Y axis from transactional to social?

Now do not assume that I am anti metadata/content types here as this is not the case at all. Content types rock when it comes to search and surfacing of related information across a site collection (and beyond if you use search web parts). What I am calling out is the fact that if the SharePoint constructs that we have at our disposal were the panacea for social collaboration, where are the best practices that tell us how to leverage them for success? Perhaps the nature of the collaboration taking place plays a part in the lack of take-up reported in the aforementioned article? Those who advocate highly structured metadata as the only true solution may in fact be pushing a transactional paradigm onto a collaborative model that is ill-suited to it?

The knowledge worker paradox – one of the reasons why user buy-in is hard

Finally for now I’d like to cover one more aspect to this issue. Last year, one of my students looked at the facets and said “Now I know why my users aren’t seeing the value that I see in SharePoint”. When I asked him why, he explained:

“Many of my users are transactional and governed by process – that’s their KPI. Here I am as a knowledge worker, seeing all of these great collaborative features, but I am not judged by a process or transaction. I don’t live in that world. I forget that someone whose performance is judged by process consistency is not going to get all excited by a wiki or tagging or a blog.”

I call this the knowledge worker paradox and it is reminiscent of what I said in part 4 where we looked at BPM vs. HPM. Each role on an organisation is multifaceted. For many roles, there is varying degrees of transactional work taking place. Accordingly some people are very much process driven just as much as they are social driven. Gross generalisations that make statements that “80% of people are knowledge workers or perform knowledge work” do not help matters. In fact they serve to feed the one size fits all mentality that has proven to be detrimental to projects when people fail to recognise that some projects have wicked aspects.

SharePoint people are almost always knowledge workers. Thus if you, as a knowledge worker who is rarely governed by transactional process, think that you have the vision to prescribe a SharePoint driven meta-utopia to meet transactional needs without having lived that world, then if your results are not what you hoped for then to me its hardly surprising.  My student in this case realised that he had been approaching his user base the wrong way. Like Jane in part 1, he did not take into account the dominant facets of collaboration for the roles that he was trying to sell SharePoint into.

When you think about it, the whole argument around records management versus collaborative document management is in effect, an argument between a transactional oriented approach, versus a social oriented one. It is the same pattern as BPM vs. HPM. In records management, the paradigm is that management of the record is more important than the content of the record. Furthermore, that record shouldn’t change. Yet with team based document collaboration, without content there is no document as such and furthermore, the document will change frequently and require less strict controls to grease the gears of collaboration.

Both records oriented people and social pundits commonly make the same mistake of my student, where they force their dominant paradigm on everyone else.

Conclusion

Food for thought, eh?

This is probably my last facets of collaboration post for a while. It is one of these series of articles that I feel has value, but I know it won’t be read by too many Nevertheless, I do hope that anyone who has gotten this far through has gotten some value from this examination and sees value in the model to help users make more informed Information Architecture decisions for SharePoint and beyond. I certainly use it now in most engagements and hope that it can be improved upon as a tool, or somehow incorporated into some of the SharePoint standards or maturity model stuff that is out there.

Remember the most important thing of all though. Despite all I have said, it is still definitely all generation y’s fault!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

                      

No Tags

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM
• The facets of collaboration Part 5 – It’s all Gen-Y’s fault – or is it?

Hi all and welcome to part four of my series on unpacking this buzzword phenomenon that is “collaboration”. Like it or not, Collaboration is a word that is very in-vogue right now. I see it being used all over the place, particularly as a by-product of the success of x2.0 tools and technologies. Yet if you do your research, most of the values being espoused actually hark back to the 1950’s and even earlier. (More on that topic in my forthcoming Beyond Best Practices book).

As it happens, Dilbert is quite a useful buzzword KPI. Once a buzzword graces a Scott Adams cartoon, you know that it has officially made it – as shown below:

So back to business! Way back in the first article, I introduced you to Robot Barbie, a metaphor that represents all of those horrid SharePoint sites remind you of a cross-dressing Frankenstein’s monster. I had an early experience with a client who championed a particular vision for a SharePoint project, only to find little buy-in within the organisation for that vision. This, and a bunch of other things, got me interested in the softer areas of SharePoint governance, where no tried and tested best practices really exist. If they did and were so obvious, Microsoft would published them as its in their interest to do so.

This all culminated in when I wrote a SharePoint Governance and Information Architecture training course last year. I read a lot of material where authors attempted to unpack what collaboration actually meant. My rationale for doing so would be to hopefully avoid creating SharePoint solutions that were Robot-Barbie Frankensteins. The model that I came up with is illustrated below:

The basic model is covered in detail in part 2. But to recap here is the basic summary: This model identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the last post, I used the model to compare and contrast the use of particular SharePoint features, such as wikis, SharePoint lists and the different aspects of document collaboration. With regards to the latter of these three, I l looked at the effectiveness of certain SharePoint building blocks like content types and site columns within the different facets.

In this post and the next, we will use the facets in a different manner. We will take a quick tour through some common philosophical smackdowns that manifest in organisational life. These smackdowns emanate because of the different viewpoints that people with particular job titles and respective bodies of knowledge have.

Any suggestion that a philosophy might be wrong or incomplete often calls into question the self-identify of the practitioner, which causes much angst among adherents. For this reason, I will leave the “agile is great” vs. “agile sucks” debate for another time, because if you search the internet for criticisms of agile you tend see really passionate programmers get all riled up and flame the hell out of you.

Instead, I will start with a relatively easy one…

Business Process Management v.s. Human Process Management

What does painting the Golden Gate Bridge and Business Process Management have in common? With both, you find that by the time you get to the end, you need to go back to the beginning again. I have personally seen organisations fill an office full of people and take literally years to define and then document key processes all in the name of various best practice frameworks or a regulatory requirement. They then find that, once a thick process manual is created, no-one actually follows it unless an auditor is watching or their performance-based remuneration is directly measured by adherence to it. Of course, I’m not the only one to notice this. In fact, the entire discipline of business process management has taken a bit of a battering in recent years.

If we consider a “process” as the means by which we convert inputs of some description into outputs, Business Process Management has long been the discipline that concerns itself with process optimisation. But in a pattern that is seen in all disciplines like Project Management and Business Analysis, someone will inevitably come along, tell you that you have it wrong or are not being “holistic” and invent a new term to account for your wrongness. In the case of BPM, we now have people arguing for various terms: such as Human Interaction Management, Human Centric Business Process Management, Non-Linear Business Process (thanks Sadie!) or Human Process Management. We will use the latter term, but they are essentially talking about the same thing.

So before we see an example Human Process Management (HPM), let’s review Business Process Management and see what the HPM fanboys are whining about.

Business Process Management

BPM is a structured approach to analyse and continually improve and optimise process activities. Process structure and flow are modelled via diagrammatic tools, allowing organizations to abstract business process from technology infrastructure and organisational departmental/jurisdictional boundaries. This abstracted view allows business to holistically examine process and increase their efficiency and respond rapidly to changing circumstances. This in turn creates competitive advantage.

BPM is often used within the broader context of process improvement methodologies such as Six Sigma (which if you have never read about it, will finally prove to you that all that high-school mathematics that you found mind-numbingly boring was actually useful). While BPM on its own provides excellent visibility of process via modelling them, Six Sigma also incorporates additional analytical tools to solve difficult and complex process problems. Thus, BPM and Six Sigma augment each-other, because process improvement efforts can be more focused via BPM modelling. Thomas Gomez, in an article entitled “The Marriage of BPM and Six Sigma", had the following to say:

“Without BPM, Six Sigma may flounder because executives lack the critical data needed to focus their efforts. Instead, the executives bounce all over the place looking for performance weaknesses, or they focus on areas where successful performance improvements provide only marginal results. With BPM, Six Sigma projects can pinpoint problems and address the underlying causes.”

But that is where the fun ends according to the BPM critics. BPM nerds have had to suffer the indignation of hurtful labels like “Sick Sigma” and stories of long term problems with innovation because of such initiatives. They cite examples such as  George Buckley of 3M, who wound back many of his predecessor’s Six Sigma initiatives.

"Invention is by its very nature a disorderly process. You can’t put a Six Sigma process into that area and say, well, I’m getting behind on invention, so I’m going to schedule myself for three good ideas on Wednesday and two on Friday. That’s NOT how creativity works."

Ouch! Its enough to make a BPM feel all flustered and defensive of their craft. Nevertheless the above quote echoes the main points made by BPM critics. That many processes are not structured, predictable or logical and therefore, BPM approaches force a structured paradigm when none necessarily exists (Mind you, many other methodologies do precisely the same). In an appropriately titled article “The H-Bomb of Business Processes: Humans”, Ayal Steiner makes a point that also cuts to the heart of tame vs wicked problems debate too.

“The modern idea of BPM stresses a well-defined business process as the starting point but this is not always the case. Therefore, in a project that involves new practices or a cross-functional learning among participants, BPM has always had a tough time dealing with the humans.”

The notion of the well-defined starting or ending point is one of the characteristics of a tame problem. Wicked problems are often characterised by poorly defined staring and ending points. In fact with a wicked problem, often participants cannot agree on what the problem is in the first place!

Critics like Steiner also argue that many roles within an organisation, tend to deal with more tacit, dynamic situations and as such spend a large amount of their work time performing collaborative human work, when compared to transactional business process work (knowledge workers is the prevailing label for this type of role). While the main area of benefit for BPM’s is its ability to increase the efficiency of a core business process, the sort of thinking required to re-think processes in a systematic manner involves collaboration and systems thinking (in other words, beyond the process in front of us and how it interacts and interrelates more broadly since the whole of the broader system is greater than the sum of its parts). This is a human-driven activity as it is based on humans collaborating and innovating.

Closer to SharePoint home, Sadie Van Buren noted this same distinction in May 2010 which was around the same time I started the development of my IA class.

Human Process Management

So if BPM is incomplete, enter Human Process Management (HPM). HPM is concerned with process that is not easily defined, nor well structured, where it is hard to prescribe the execution of the process based on some model of the business. With human process, it is generally known how to achieve an intended result, but each case is handled separately and requires tacit judgment (for both decisions and flow) as part of the process. There is not enough standardization between instances of the process that allows for a formal, complete and rigorous description of the process end-to-end.

The obvious downside of human processes, say the critics, is that they are far too fluid and dynamic to be made part of an Enterprise BPM system. As a result, these processes tend to be handled through email, which in turn contributes to information overload and poor information worker productivity – precisely why we look to tools like SharePoint in the first place! The implication of HPM is that we need to shift emphasis to tools and practices that help us deal with unstructured or ad-hoc processes (and the information created/used during that process) more so than tools that deal with the well-defined world of BPM.

To be fair to the BPM crowd, these above criticisms will be seen by BPM practitioners as naive, since from their point of view, the less structured side is simply a part of the entire BPM spectrum. They argue that critics do not properly understand the principles and philosophy of BPM in the first place (Agile and PMBOK defenders say essentially the same thing when defending from critics). Supporting this counterargument is a key theme for BPM success that is regularly emphasised. That is, the critical pre-requisite of clarity of purpose and shared understanding of the end in mind. Mohamed Zairi, in a paper called “Business process management: a boundaryless approach to modern competitiveness” stated:

“The achievement of a BPM culture depends very much on the establishment of total alignment to corporate goals and having every employee’s efforts focused on adding value to the end customer.”

Therefore the BPM crowd are arguing for the same human process that HPM base their criticism on. Developing a culture of alignment to corporate goals is very much a human process. Are the HPM fanboy criticisms well founded or is it more a case that some BPM guys forget about strategic goal alignment and optimise process in isolation?

What do the facets say?

Clearly, there is a natural tension between these two polarities of BPM and HPM and this often plays out in organisational life in how we collaborate to deliver organisational outcomes. While there have always been process nazis, the emergence of social collaboration platforms that do not have a great deal of formal structure (think tagging and folksonomies) has led to a great deal of debate and self examination in BPM circles and beyond. Understanding these traits is critically important on the use of SharePoint tools, because SharePoint – and in particular SP2010 offers features for both BPM and HPM aficionados. Putting the two together however might risk Robot Barbie scenarios.

Straight away, it seems that the transactional vs. social axis of the facets of collaboration neatly explain the Business Process Management (BPM)/Human Process Management (HPM) challenge. Both areas are concerned with producing an output or getting something done. Therefore I have drawn BPM and HPM leaning toward the task side of the model. HPM proponents argue that human process is unstructured or semi-structured, dynamic, intertwined and borderless, which fits in well with the task/social trait of process and insight. BPM naturally fits into the lower transactional half where inputs are well defined.

While I would agree with the assertion that many processes are ill-defined and rely on tacit knowledge to be completed, HPM proponents go further though. For example, Ayal Steiner who I quoted earlier, argues that “analysts are now realising that human processes account for 80% of the business processes carried out in most organisations”. That is a big call, in effect, arguing that the majority of workplace interactions occupy the social quadrants above. I disagree. From my experience, most organisational roles have extremely varying degrees of transactional vs. social collaboration and some roles are in fact dominated by transactional collaboration. Perhaps there is some confirmation bias going on here, where knowledge workers who put in collaborative systems tend to think that everyone are knowledge workers too.

Here is an example. Mrs CleverWorkarounds used to be a medical nurse. When I first showed her this model I asked her to describe where nurses would fit in terms of their collaboration. She indicated two areas.

• Firstly, nurses are strongly linked by trait and transaction. This is because they all have a minimum degree of knowledge and skill. As stated in part 2, the key tell-tale sign of a role with transactional collaboration is how easily individuals performing that role can be replaced by someone else with similar experience at short notice. Supporting this, if a nurse is sick or unavailable, a replacement nurse can be called in to perform the same tasks.  Collaboration between nurses according to Mrs Cleverworkarounds is quite transactional as well. Routine and process consistency via tracking the status of patient care is a critical task – patient status is everything. Thus, data driven tools with version history and well defined inputs make this form of collaboration easier. In fact, Mrs CleverWorkarounds taught herself InfoPath and SPD Workflows because she was so convinced that automated forms with consistent audit trails via workflow would make her job easier.
• Yet at the same time, the sort of collaboration between nurses and patients is completely different and highly social in nature. No process is going to govern the interaction between nurse and patient. The type of care and counselling to get someone well is going to vary the type of interaction. A broken leg is one thing, health problems from say – alcoholism is something else entirely. The latter has much deeper symptoms than just the illness as presented. Here the focus is on patient well-being and goes beyond status of meds, when doctors have visited or accurate handover notes from one nursing shift to another.

State machine workflows?

Interestingly, even seemingly well-defined business processes tend to have ad-hoc and dynamic aspects to them. When there is an exception to the standard process, those exceptions tend to be handled in a relatively ad-hoc, case-by-case manner. Microsoft developer Pravin Indurkar cited an example of a seemingly transactional purchase ordering system.

“Often the business processes contain a prescribed path to the end goal but then there are a lot of alternate ways the same goal can be achieved. For example, a purchase order can contain a prescribed path where the PO goes from being created, to approved, to shipped, and then to completed. But then there a multitude of other ways in which the PO can be completed. The PO can get changed, or back ordered or cancelled and then Reopened. All these paths must be accounted for.”

Indurkar studied the purchase order system of a small business and found that apart from the one standard traditional order fulfilment process, there were about 65 different variations on the same process depending on the nature of the order. This is when BPM diagrams start to get scary. If you think that this workflow below is scary, then be more scared. It is page 12 of a 136 page process!

Naturally, trying to hardwire such a large number of alternate paths is very difficult and traditionally, there were two ways in which this was dealt with;

• Either the business process was hard wired to accommodate all the paths as shown in figure 1, which made the implementation of the business process extremely complex, brittle and hard to maintain.
• The alternate paths are simply not dealt with and any situation of the ordinary was dealt outside the domain of the process. This meant that tracking and visibility were lost because people would create manual systems to track such out of the ordinary situations. The facet diagram below illustrates this:

In Indurkar’s article that I quoted with the purchase order example, he argued that the solution to this sort of problem was via state-based or state-machine workflows which SharePoint has supported in a basic fashion, out of the box since SP2007. This kind of workflow, if you are not aware, is when the workflow waits for one or more events to move it into another state. There is no sequence as such, because this new target state can be any of the defined states in the workflow. This makes state workflows reflect the unpredictable nature of process variations.

Thus, it could be argued that BPM is not incomplete as what the HPM fanboys think, but that critics have a less than holistic understanding of the craft?

Conclusion: A Process Analysis Tool…

To be honest, I don’t want to answer the question of which fanboy is right because it is a bit of a zero sum game. When you think about process, many seem to have elements of transactional and social in them (just like job roles). For example, an “Approval” decision diamond in a business process diagram will determine the path a process takes. Apart from stating the fact that this process is a gateway where a decision is made, this says nothing about whether the activity of making that decision is transactional or social. In some processes the decision may be made by a rigorous data driven process (like a point-score based credit check for a loan applicant). In others it may be on gut feel (such as choosing the right applicant for a job position).

So to me, whether you are the most regimented process nazi or the most cowboyish non-conformist hippie, modelling a business process according to its ratio of transactional to social facets is probably very useful indeed to complement a BPM model. It help us understand how much tacit judgement is required in a given process and whether modelling every variation in a sequential workflow is worthwhile. Check out some examples on how this could be done below. In first example on the left, a business process where the majority of the steps are performed by tacit judgement might look like something like how I have drawn, with a task based social dominance. If the process in question indeed looks like this, then attempting to document every minute variation on the paths the process can take might not be worthwhile. Perhaps documenting the broad process (within the constraints of any compliance regime requirements) might be a better idea. In the second example, the process seems to be oriented around a repeatable set of choices (task based transactional dominant). As a result it may be worthwhile formally documenting these variations.

By combining these “process diagnostics” with the actual diagram, we might now offer additional insights into how the organisation really works with a certain process and do crazy stuff like produce something akin to my mockup below:

Hell, throw in a RACI chart and now you start to see process accountabilities as well!

Of course, you could always remove the task/trait axis if it is not needed and simply use a sliding scale. Nevertheless, what this shows is that the facets of collaboration model offers an extra dimension to any process being modelled and would help many to better understand the nature of the process being modelled, as well as strategies for improving that process via SharePoint.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

p.s If you are a real trainspotter/glutton for punishment and want to dive deeper, google “Human Interaction Management” and “Role Activity Diagrams”

                      

No Tags

Hi

This is part 2 of a quick (but huge) post on my experiences working with SharePoint Designer 2010 workflows and Forms Services. In part 1, we used the scenario of an employee termination form, and sacked Justin Bieber. Now we want to ensure that the SharePoint user experience for sacking Justin Bieber is seamless and intuitive.

Truth be told, I have never actually heard a Justin Bieber song because we have not had a television in the house for over a year. Ignorance is bliss, but I have seen enough news reports that I still want to sack him!

In part 1, we examined the ability of SPD2010 to leverage InfoPath for tailoring forms used by workflows. We then covered creating a workflow utilising the Start Approval Process action, which enables us to do a couple of cool things without custom programming.

Now we are onto the next two steps.

Step 2: Dealing with WrkTaskIP.aspx

As we covered in part 1, WrkTaskIP.aspx will render the link to the InfoPath form that triggered the task via the line <% SPHttpUtility.NoEncode(m_pageDescription,Response.Output); %>

   1:  <table>   

   2:  <tr>   

   3:        <td width="10" valign="center" style="padding: 4px;">   

   4:            <img IMG SRC="/_layouts/images/Workflows.gif" alt=&amp;lt;%SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(GetLocString("WrkTask_PageTitle")),Response.Output);%&amp;gt;/>   

   5:        </td>   

   6:        <td>   

   7:            <% SPHttpUtility.NoEncode(m_pageDescription,Response.Output); %>   

   8:        </td>   

   9:  </tr>

  10:  </table>

  11:  <InfoPath:XmlFormView id="XmlFormControl" runat="server" style="width:100%;"/> 

Our second step is to make a copy of WrkTaskIP.aspx. I imaginatively called my copy WrkTaskIPFS.aspx (FS meaning Forms Services). I then simply removed the entire <table> section from the above code, leaving behind only the code that embeds the InfoPath form (<InfoPath:XmlFormView id="XmlFormControl" runat="server" style="width:100%;"/>)

The next step is where things get a little tricky. I really don’t want to go off onto too much of a tangent here except to say that you should read up on the relationship between site content types and list content types, as well as the content type propagation issues encountered when using XML Based Content types (which the workflow created tasks are).

We need to modify the task content type created by the workflow action to refer to the WrkTaskIPFS.aspx file. Take care to determining what the content type name is. This is because sometimes the name of the content type created when the workflow is published is not what you expect – especially if you have set up previous Start Approval Process workflow actions before now. So if you are unsure of what content type the workflow created, just trigger the workflow and check the content type of the task created. In my dodgy example here, the content type name is “Approval”.

Now that we have found the content type we get to the tricky bit that I alluded to earlier. You might think that we just select the site content type in SharePoint Designer and change the reference to the display and edit forms right? After all, I show below that SharePoint Designer happily lets you do it?

If you make the change from WrkTaskIP.aspx to WrkTaskIPFS.aspx for the edit and display form setting, and then refer to the task list and click to edit one of the tasks, you will be disappointed. As you can see, we are still referring to the old form page because the link has not disappeared.

The problem is that changing the display and edit form on the Approval site content type has not propagated to the Approval content type applied to the Tasks list. I tried to propagate the settings using a Gary Lapointe stsadm extension, but it seems that extension deals with column propagation and not all properties.

The workaround is to apply the same setting change to the task content type applied to the tasks list. In SharePoint Designer, choose the Tasks list (or whatever task list you have associated with your workflow), and scroll down to display the content types assigned to it.

Click on the content type of interest (in my case “Approval”), and you see essentially the same content type properties screen you see when editing the site content type. The breadcrumb is the giveaway that you are working with a list content type and not the site content type. Change the reference to WrkTaskIPFS.aspx as shown below.

Now I can click on my task to sack Justin Bieber and we have removed the default link as intended.

Okay, now that we have dealt with the hyperlink to the form, lets add the hyperlink into the InfoPath form associated with the task.

Part 3 – Dealing with InfoPath

Now we need to add a reference back to the original employee termination form. So lets get back to our workflow and check it’s properties where we can get to the forms generated. I click on “TerminateEmployee” and we are back in InfoPath.

I am going to put the hyperlink in a new row, right above the status header. To do this, I need to insert a row above status and then enter a nice descriptor.

Now let’s deal with the hyperlink. Here is yet another trap for younger players. Your first instinct might be to add a hyperlink control to the form. If you try this, it will not behave like a form you created from scratch. A screenshot below shows what happens.

Unlike an InfoPath form that is created from scratch, this form is bound to the data provided by the workflow action. Therefore if you try and drop on a control to the form, you will be prompted to bind to a field of the existing data source. This is not how we are going to do this, but I will go through the motions anyway.

Insert a hyperlink control, and from the fields listed, choose the one called Related Content

Amazed by your cleverness, you excitedly publish the form and check out the task! Yeah baby! you say to yourself! I have my hyperlink.

You now click on the hyperlink to see the magic. At this point one of two things will happen. If you happened to use a space in the original form name, then you will get a 404 error because the hyperlink control is dumb and not escaping the space in the URL. If you did not use a space in the name, you will get prompted to open the form in the native InfoPath client.

We are back to where we started. So we are foiled – or are we?

Part 3a – A clever workaround

Clearly, utilising the built in Related Content field with the InfoPath hyperlink control is kind of naff. So let’s have another crack at it. Return to your task form and delete the hyperlink control you just created. What we will do this time is add an additional field to the InfoPath data source. In InfoPath, take a look at the data pane. At the bottom is a link “Show advanced view”. Click it and we can take a look at the data source in more detail.

The next step is a lesson in Olympic class Microsoft usability eliteness (NOT!). Right click on the myFields dropdown and choose Add. Name the field URL and select Hyperlink as the data type as shown below.

Click OK and your data source should now show our newly created field called URL (my:URL). Click on this field and from the drop down and choose Properties. (We are going to set the default value of this hyperlink to our original form, but append the &OpenIn=Browser to the URL).

Click the fx button and lets make a formula. If you have played with InfoPath formulas, you might think that all we have to do is use the concatenate function on the Related Content field with the string “?OpenIn=Browser” as shown below.

concat(WorkflowLink, "?OpenIn=Browser")

Workflowlink, by the way, is the reference to the original Related Contnet field in the InfoPath data source. Just click Insert Field or Group and find Related Content

So will it work? Actually many times it will. So either drag this completed field to the form to create the hyperlink control, or insert the hyperlink control from the ribbon and bind to the field. This time our new field (my:URL) is in the list to choose from when binding the hyperlink. (oh -  make sure you are in advanced view, not basic view to choose your URL field).

So having done this, you will have a primed hyperlink control on the form. Publish the form and let’s have a look at the effect when a new workflow task is created…

Looking positive, but what happens when we click it?. In my example, we get a nasty 404. If you look closely, this is because I have a space in the URL name. *sigh*, InfoPath certainly doesn’t make it easy does it? So we need to revisit our little formula to deal with the unencoded space.

This is the part of the blog post where I feel dirty. InfoPath does not have a string replace function, and ideally what I want to do is replace any occurrence of a space “ “ with an encoded space “%20”. The built in translate() function will not suffice because it will only translate one character for another, not one character for three.

For the geeks, InfoPath uses the XPATH 1.0 spec, however XPATH 2.0 was released in 2007 and does have a replace function. What a pity InfoPath 2010 does not appear to use XPATH 2.0.

So in my case, I will create a formula to handle one space only. Yeah I know this is lame, but given that you have control of the filename generated for InfoPath forms when you make a submit connection, this is not an overly big deal – just bloody annoying. If you avoid spaces in filenames altogether, you can you my easier concatenate formula above.

I have dealt with the space, by using two built in substring formulas in combination with the concat function as shown below.

concat(substring-before(WorkflowLink, " "), "%20", substring-after(WorkflowLink, " "), "?OpenIn=Browser")

What I do here is search for the space and return all text before it, add a %20 and then return all text to the right of the space to create my URL.

Now lets republish and take a look. Aha! now it works. We can now view the form in the browser, have control over where the link is placed on the form and can manipulate the form URL.

Taking a breath

So if we step back and review what we have done.

We changed to the newer, cooler, “Start an approval process” workflow action. By the way, in case its not clear amongst the screenshot-hell that is an InfoPath post, the reason we did this was because the older workflow actions do not provide a reference to the Related Content/Workflowlink field. Yup, that’s right. The Collect Data from a User, Assign a Form to a Group and Assign a To-do Item workflow actions do not appear usable with the technique I described above.

That is a minor point anyway, because the new SP2010 specific workflow actions are much more powerful and flexible and should be used. We have barely scratched the surface in these posts and I encourage you to have a good look at the new process actions.

We then made a copy of WrkTaskIP.aspx and then changed the settings of the task content type to use the copy (WrkTaskIPFS.aspx). We also encountered a glimpse of the content type setting propagation issues that developers have to contend with on a daily basis. We modified the copy to not provide a reference to the original form, and instead, modified the task form using InfoPath to provide a hyperlink to the original form, manipulating the URL, ensuring that it will open in the browser.

Although I would not rate this as the cleverest of clever workarounds, its not too bad and certainly won’t be the kind of action that would prevent a future service pack being applied.

Bonus Part 4

So did you think this is the end? No sir. I am going to show you one other neat trick that this approach can enable. To explain, let’s do a little more form pimping. If we return to our employee termination form, I am going to add a picture button that has a rule to submit for form and then switches the form view to a “thank-you please come again” type thing. Below is the new form with the sexy “terminate” button and the new view after it is submitted.

This is a very common InfoPath scenario, and the problem is that if the user re-opens this form, they can again, click the submit button and the rules will be re-run. This normally would necessitate some logic in the form to test if the form has been submitted already. Adding logic to the submit process on a form is not a hard thing to do, but if you check the InfoPath toolbar that is enabled by default, there is a print preview button. I wonder what happens when we click it?

Interesting eh? No toolbar and no button. This is exactly what I want to happen when a user clicks on the task link to review the original termination application.

So how about we change the URL to load up the print preview of the browser enabled form? If we examine the URL generated for this form it uses Print.FormServer.aspx instead of FormServer.aspx. If you load up any browser enabled InfoPath form, you can remove the toolbar and buttons by calling Print.FormServer.aspx instead.

Thus if we take this

http://sp/sites/FormDemo/_layouts/FormServer.aspx?XmlLocation=/sites/formdemo/forms/justin%20bieber.xml%3Fopenin=browser

and change to this:

http://sp/sites/FormDemo/_layouts/Print.FormServer.aspx?XmlLocation=/sites/formdemo/forms/justin%20bieber.xml%3Fopenin=browser

… we achieve our goal.

So how about we generate this as the default value for our URL field on the task form. The Related Content URL supplied from SharePoint is the full path to that content. e.g.

http://sp/sites/FormDemo/Forms/JustinBieber.xml

When we look at the Print.FormServer.aspx URL above and break it up into its components, we need to:

• Create the site collection URL
• Create the string "_layouts/Print.FormServer.aspx?XmlLocation=/"
• Grab the relative path to the form
• Create the string "&OpenIn=Browser"

Creating the site collection URL is easy as their is a built in formula called SharePointSiteCollectionUrl(). Additionally, creating the relative path can be done by taking the Related Content field (called WorkflowLink) and removing the host part of the URL. Once again built-in formulas come to the rescue here. SharePointServerRootUrl() will return the hostname of the site and substring-after() will return everything to the right of the matching substring. Therefore the formula

substring-after(WorkflowLink, SharePointServerRootUrl())

will strip the hostname from the URL to the form, leaving us with the relative path.

Stringing that all together into a concatenation creates the following formula.

concat(SharePointSiteCollectionUrl(), "_layouts/Print.FormServer.aspx?XmlLocation=/", substring-after(WorkflowLink, SharePointServerRootUrl()), "&OpenIn=Browser")

to render a sample URL of:

http://sp/sites/FormDemo/_layouts/Print.FormServer.aspx?XmlLocation=/sites/FormDemo/Forms/Justin Bieber.xml&Openin=browser

But the space…

Those of you that have not fallen asleep at this point might notice that we have re-introduced our problem with the non encoded space. That can be dealt with using the substring-before and substring-after formula that we used earlier. Assuming the space is in the form name, we build a string up to the form name, use substring-before to grab everything prior to the space and substring-after to grab everything after.

The resulting formula looks like this.

concat(substring-before(concat(SharePointSiteCollectionUrl(), "_layouts/Print.FormServer.aspx?XmlLocation=/", substring-after(WorkflowLink, SharePointServerRootUrl())), " "), "%20", substring-after(WorkflowLink, " "), "&Openin=browser")

Ugly enough for you?

The reality is that spaces are deadly here and you are better off utilising form logic that does not use spaces and stick to the simpler formula. The example above might be interesting from a learning point of view, but there are a number of ways that this formula could trip up and produce a malformed URL (what if there is no space in the filename for example?)

Conclusion

Notwithstanding that InfoPath formulas suck in terms of needed functions, we now have a task form that will link to the original InfoPath form and display the form in print-preview mode. All in all not a bad effort, and an interesting exploration into what InfoPath can do.

I would have liked to make the URL friendlier of course, and given that this is InfoPath we are talking about, I fully expect someone to post a comment telling me the elegant, perfect way to do what I have done here

Thanks for reading

Paul Culmsee

www.sevensiogma.com.au

                      

No Tags

A very long time ago now, I had the ambition to write an end-to-end blog post series called “A Humble Tribute to the Leave Form”. The intent was to show InfoPath Forms Services 2007 in all its glory – from its initially seductive, demo friendly first impressions, through to all of the dodgy workarounds and .net code required to get it to adequately handle a relatively simple business process like employee leave applications.

As it happened, I got through seven and a half blog posts and never finished it as events kind of overtook me. Its a pity because I didn’t get to the nasty bits. But one of the side effects of getting as far as I did, was that I ended up getting a lot of work developing leave forms!

Thus, now that SharePoint 2010 is upon us, it was inevitable that I would eventually get called to develop a leave form for this new edition. I now have done so, and in the process learnt a couple of new things that I thought were blogworthy – especially around getting things to play nice in a sustainable manner.

I came to realise that anytime you write any content that involves InfoPath, you end up with a stupid number of screenshots, and you are perpetually torn on the amount of detail to cover. So this time, rather than do a twelve post monster, I’ll just do 2 posts (real programmers will still find this post waffly but hopefully normal humans won’t).

I am not going to do a total beginners course here, I will assume instead you have done some basic InfoPath and SharePoint Designer workflows previously, and now want to know some interesting ways to do a general approval type process using SharePoint 2010. My main focus here is to deal with handling browser based InfoPath forms with SharePoint Designer workflows.

Setting the scene

To set the scene, I thought that instead of a leave form example, lets use an employee termination example instead. I have published such a form to SharePoint as a site content type called Form-EmployeeTermination. Below is the form with four perfectly legitimate reasons why someone should face instant dismissal.

Okay I realise there is a bit of testosterone there – but as far as I am concerned, even one of those reasons are grounds for instant dismissal!

To complete the scenario, I thought to myself, who in all the world right now would I most like to sack. The answer came quickly…

So here is the scenario. I am going to show how to leverage SharePoint 2010 new features to sack Justin Bieber. As part of sacking Justin Bieber, we will optimise the workflow to work with forms services and play nice with browser based rendering.

How it was…

Now in SharePoint 2007, you would likely publish the above form as a content type, associate that content type to a forms library and create a SharePoint designer workflow for that library. Then it would be exceedingly likely that you would utilise one of the three out of the box task based workflow actions, namely;

• Collect Data from a User
• Assign a Form to a Group
• Assign a To-do Item

The reason you would utilise one of these is because they create a task for someone to take an action. So for example, a user requests that Justin Bieber be terminated, a task is assigned to Justin’s boss to terminate him. When said boss has marched Justin Bieber out of the office, he then marks the task as complete in SharePoint.

Each of the above three actions served a particular purpose.

• Assign a To-do Item simply created a very basic task with an “Approve/Reject” button.
• Collect Data from a User allowed you to customise the task form and collect additional data beyond the Approve/Reject
• Assign a Form to a Group did the same as Collect Data from a User, except it could assign the task to multiple users.

I tended to use Collect Data from a User most of the time. because it passed you the ID of the newly created task in the task list. This was important if the task contained more than just an Approve or Reject button. Continuing our employee termination example, we might have a checkbox to note whether Justin Bieber cried or not when he was sacked.

Therefore, if the workflow needed to take an action based on whether Bieber was a blubbering cry-baby or not, then Collect Data from a User was the only workflow action that was suitable as we would need to refer to the task later, to check the Cry-Baby column.

These workflow actions also did a few other things behind the scenes. The approve task created was actually a site content type, with its own customised edit task form. SPD 2007 would create auto-generated ASPX pages for the task, incorporating any custom fields created. (If you want more detail about that then visit the “Theory Interlude” section of this post.)

How it is now…

One of the major improvements of SPD workflows with SharePoint 2010 is the integration of InfoPath. In SP2010, the aforementioned three workflow actions still exist, but when you use them, the customised task form is created as an InfoPath form embedded into the built in WrkTaskIP.aspx page, instead of an auto-generated ASPX page.

The screenshot below shows the basic idea. I created a simple list workflow using the Assign a To-do Item and published it. If we examine the workflow properties after publishing, we see that the workflow initialisation form and custom task are listed. I have highlighted the form for the task below.

Note that there is now a form with a name that matches the name of the To-Do action. If we click on this form, we can now edit it in InfoPath and republish it. Below is a before and after dodgy InfoPath pimping effort of the Terminate Employee task form.

Before:

After:

If I run this workflow on an item, check out the task created. It simply renders the published InfoPath form that I modified.

So all in all, this is a great improvement over SharePoint 2007 SPD workflows. Being able to utilise InfoPath to control the look and feel of workflow forms is very handy indeed.

Having showed you this now, I want you to forget it! For reasons that I will explain later, these three workflow actions should be considered legacy in many circumstances.

Dealing with Forms Services

Our next stop on our journey to sack Justin Bieber is to deal with a common problem that occurs when SharePoint Designer Workflows are associated with published InfoPath Forms. If we take another close look at our dodgy pimped task form, you will see that there is a reference to the original form that triggered the workflow. It is a hyperlink next to the “This workflow task applies to” text.

The problem is when we click the link, instead of the form loaded in the browser, we are prompted to save or open an XML file as shown below.

This is very common issue that is frustrating for new players. The related list item link always references the original list/library and item that the workflow was triggered from. It has no idea that this is a URL to be rendered via forms services. The default URL for the above example when referred to as an item in a form library is

http://sp/forms/Justin Bieber.xml

Yet when rendered within forms server, the URL is:

http://sp/_layouts/FormServer.apsx/XmlLocation=/forms/Justin%20Bieber.xml&DefaultItemOpen=1

So, the problem is that the wrong URL is being passed into the task item as the related list item. The forms services URL is never used and therefore the form is not displayed in the browser. Ages ago, I documented a particularly crap workaround, before someone pointed out to me that if you simply add ?OpenIn=browser to the original URL, it will auto-magically redirect to the forms services URL. i.e.

http://sp/forms/Justin Bieber.xml?OpenIn=Browser will render an InfoPath form via forms services.

So our mission here is to change the reference to the original Justin Bieber termination request. By appending the OpenIn=Browser parameter to the URL, we ensure that the form is rendered by forms services.

Digging Deeper

If we take a closer look at the task as it is rendered in the browser, you can see that the InfoPath form is actually embedded inside another page. You might also notice that the hyperlink to the Justin Bieber termination form that triggered the workflow, is not part of the embedded InfoPath form. It is part of the surrounding page.

The page that displays the workflow task is called WrkTaskIP.aspx (presumably Workflow Task for InfoPath?) and is a system file that resides in the 14 Hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS – this file also exists in SharePoint 2007 but is only used with Visual Studio workflows).

Now we all know these days that anything that lives in the Layouts folder should be treated with caution, and directly modifying this file is a giant no-no. Fortunately, as I will show in a bit, we can make a copy of this page and tell our task content type to use that copy.

But since we are here at the default page, lets have a peek inside this file to the relevant section and see what is going on.

   1:  <table>

   2:  <tr>

   3:      <td width="10" valign="center" style="padding: 4px;">

   4:          <img IMG SRC="/_layouts/images/Workflows.gif" alt=&lt;%SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(GetLocString("WrkTask_PageTitle")),Response.Output);%&gt;/>

   5:      </td>

   6:      <td>

   7:          <% SPHttpUtility.NoEncode(m_pageDescription,Response.Output); %>

   8:                 </td>

   9:  </tr>

  10:  </table>

  11:  <InfoPath:XmlFormView id="XmlFormControl" runat="server" style="width:100%;"/>

Now you don’t necessarily have to be a developer to work out that the line <% SPHttpUtility.NoEncode(m_pageDescription,Response.Output); %> is generating the hyperlink to the original form. (Actually if you are a developer then check this excellent article for a deeper examination, albeit for SP2007). Now a developer could easily take a copy of this page and modify some JavaScript code to add the ?OpenIn=Browser string required to make it render properly.

But not all of us are developers and I have another idea. Let’s make the copy of WrkTaskIP.aspx, but remove the hyperlink reference to the form altogether. Instead, lets use the embedded InfoPath form to do the job of rendering the hyperlink to the form. At least that way, we have more control over the hyperlink that is generated.

To do this, we have three major steps to complete.

1. Changing the workflow action to “Start Approval Process” to take advantage of the richer SharePoint data it provides
2. Making a copy of WrkTaskIP.aspx and updating the task content types
3. Modifying the task form to display the correct hyperlink

Step 1: The one workflow action to rule them all

First up, we are going to use a new workflow action that is SP2010 only. The reason for doing this will become clear later. For simplicity I will create a list based workflow called “Employee Termination”, as opposed to a reusable one.

Create a new workflow and assign it to the list where your form content type has been published to (In my example it is simply a form library called “forms”).

In the newly created workflow, choose “Start Approval Process” from the actions button in the ribbon.

Now up until this point, you would think this looks and feels like a regular workflow action. But as you will see, this innocuous looking action packs a hell of a lot of punch! First up, lets for now, assign this approval process to one user – the administrator account. We do this by clicking on the last parameter – the hyperlinked “these users” link.

While we are here, let’s take a quick look at this screen. This workflow action allows you to add more than one participant, as well as set some defaults, such as the title of the workflow task, as well as being able to set a task duration as shown below.

At this point we have configured the workflow participants. The next step is to delve into an innocent looking hyperlink that opens up a world of possibilities.

Click on the “Approval” hyperlink and you will be presented with a page that controls this new workflow action. This innocuous looking page has within it some impressive functionality. We will examine a little of it as we work through this scenario.

Let’s give this task a better name than “Approval”. We will call it “Employee Termination Request”.

Next step, we will add an additional field to the workflow approval task. I previously referred to the need to know if a terminated employee cried like a baby when they were sacked, so let’s add a Boolean field to represent this.

From the “Task Form Fields” section above, you will see a “new” button. From there you add a new field and set its type.

Note that once the field has been added, you can also control if it required or not in the resulting form.

Next, let’s make the form more user friendly by re-labelling some of the task outcomes. Again we will not get into the depth of this here – you can think of it as customising the buttons on the soon to be created task form. Let’s change Approve to “Terminate!”, Rejected to “No Way!”, and add a third task outcome called Warning with the button text of “Reprimand!”

Now that we have set these initial parameters, lets save the workflow and examine the InfoPath form that has been generated.

Using the breadcrumb in SharePoint Designer, choose the “Editor” link and then choose “Workflow Settings” from the ribbon

At this point. there are no generated InfoPath forms (note that the Forms section is empty in the bottom right). 

Let’s publish this workflow and take a look at what happens in the aforementioned Forms section.

Aha! Now we have two forms. One is the workflow initiation form and the other is the task form. Taking a peek at the generated task form in InfoPath, we can see that it reflects the settings we applied earlier (check the buttons).

Additionally, a workflow task content type has been created with the same name. That task has been configured to use the above form.

This content type is important as we need to make a modification to it in part two.

Conclusion

Since the workflow has been published, let’s test where we have got to. I have my original Justin Bieber sacking form in the form library, so let’s manually trigger the workflow and take a look at the task created.

If you look at this form, you can see that my adjusted buttons have been created, and the additional crybaby Boolean field has been created.

At this point, this post is getting kind of huge, so let’s leave it at step 1. In part 2 of this series, we will make a copy of WrkTaskIP.aspx, modify the task content type to use the copy and then tweak the above form to display the reference to Justin Bieber via forms services. I’ll also show you another neat trick (and some InfoPath suckiness too).

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

                      

No Tags

I’ve written this post to document a dumbass thing that I did and the error that it caused. Hopefully it might help someone googling in desperation sometime…

The popularity of the “Tribute to the humble leave form” series over at SharePoint Magazine, has meant that we actually get a few gigs implementing – surprise, surprise – InfoPath leave forms with SharePoint Designer workflows! This was actually quite unexpected, as I wrote that series as a joke and for end-user training purposes.

Now, I fully realise that many people don’t like tools like SharePoint Designer in the hands of mere mortals, but I personally think it is a terrific means to encourage buy-in and user evangelism and I encourage its sustainable use. Although “real developers” may disagree with me here, SPD workflows enable quick results without the embarrassing aftermath of premature code compilation (which always leads to frustration, right girls? ).

Anyhow enough sexual innuendo – here is my error with my lessons learned

The symptoms

Recently, a happily running leave form workflow ground to a halt with an error as shown below. What the screenshot below shows is that the workflow died right after a “Pause for duration” workflow action. (Note the “pausing for 2 minutes” line, just before the actual workflow error).

Now, the interesting thing here is that the pause action never happened. The workflow bombed out straight away and there was no pause at all. Yet, the fact that the pause action logged to the history list meant that it attempted to do so. It seemed that the pause action ran for long enough to log that it was about to pause, but died when actually trying to.

The pause action occurred in step 2 of my workflow, but it is worthwhile showing you the first workflow step first.

Below is a screenshot of step 1 of the workflow. This first step is called “Modify Item Permissions” and we are using the codeplex custom workflow actions to modify permissions of the submitted leave form, ensuring that only the requestor of the leave (and their boss) can see or modify the form.

The step in the workflow, called “Manager Approval”, shows where we pause for 2 minutes. The reason we pause is to get around another workflow error that I will explain at the end of the post. After the pause action was completed and the workflow recommenced, it performed a “Collect data from user” task as shown below. This created a task for the requestors manager to approve the leave request.

We know that the “Collect data from user” action never ran, because the “Employee Leave Approval” task never actually got created in the task list. Thus, we know the error occurred at the pause action. Or, did it?

This error occurred consistently whether the workflow was manually started or auto-triggered. Checked all the usual suspects – timber jobs ok, permissions unchanged and working well, etc. Scanning the ULS logs at this time showed an interesting error with a much less interesting stack trace (that I have pasted at the end of the post for readability).

“Unexpected    ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads”

Hmm, what is TrackedRequests and why is a request not found? Googling that error message wasn’t much help at all. Although it is quite common, nothing matched my particular context. But then I received a lucky break. When I cancelled the running workflow that was in this error state, I received a new error that made it quite easy to work out what was going on.

WinWF Internal Error, terminating workflow Id# 02334a17-3211-4d30-902f-bf34e20354c6    
Unexpected    System.Workflow.Runtime.Hosting.PersistenceException: Object reference not set to an instance of an object. —> System.NullReferenceException: Object reference not set to an instance of an object.     at DP.Sharepoint.Workflow.Common.RemoveListItemPermissionEntry(SPListItem item, String principalName, Boolean breakRoleInheritance)    

It was this error that gave it away. For a start, the method being called was DP.Sharepoint.Workflow.Common.RemoveListItemPermissionEntry and the exception was a null reference. RemoveListItemPermissionEntry sounded suspiciously like the permission based workflow actions of the “Modify Item Permissions” step as highlighted below.

But wait… the workflow never failed at this line at all. It actually failed at the first action of the next step (“Manager Approval”)  with the “request not found in the TrackedRequests” error. Interesting, eh?

Let’s put aside the issue of what step and what action the workflow failed on for a moment, and examine the second error message more closely. If you examine the “Modify Item Permissions” action highlighted above, can you think of any reason that I would get a null reference exception?

Ah! What happens if the previous action called “Set Variable”, set a blank or null value? I suspect that the “Grant permissions on an item” workflow action will attempt to change permissions of the item to a blank or null user. The result? That workflow action will die with a null reference exception – precisely what the error states.

When I checked the source of the variable “LineManagerAccount”, it was looking up a contact list for the manager of the requestor. Sure enough, it did turn out that that column was blank for some users. Thus, a simple exercise in input validation combined with a small correction to that list item and the problem was solved.

Further questions and further information

I could stop this post there I suppose and perhaps someone, sometime might find this post and think “Wohoo!”. But this problem raised a couple of issues, as well as made it clear to me that I had been stupid in how I designed this one. Let’s tackle them one by one.

1. When did it die again?

Clearly the error that caused all of this, occurred at the last action of the “Modify Item Permissions” step. We know this because the step before was where the lookup to the contact list happened, and this is where the null value came from that caused the exception. But then why did the workflow not stop at this point? Why did it continue onward and attempt to move to the “Manager Approval” steps and die on the “Pause for duration” action?

Whether this is default behaviour of SPD workflows or a logic fault in the exception handling code in the codeplex-based “Grant Permission on an Item” action, this makes life hard to troubleshoot because the error message never made sense. I only found out the true root cause when I terminated the workflow manually and got lucky because the offending exception suddenly appeared.

So, the conclusion to draw? If your SPD workflow dies with “ERROR: request not found in the TrackedRequests” in the logs, it may be that the real cause of the problem is a previous workflow step and not the step where the workflow actually stopped.

2. Paul is a dumbass

Okay, so let’s talk about lessons learnt. Some people reading this may wonder why I never used Active Directory or the user profile store to store manager details for a user and to do the lookup from there. The answer is that this contact list approach simply made sense for this client and this is actually not the dumb thing that I did. The dumb thing that I did was to forget that all of the necessary business logic and data validation steps could have been performed in the InfoPath form itself.

Remember that InfoPath forms can have data connections to all sorts of sources such as SharePoint lists, web services and relational databases. (I am not going into detail on how to do that here because I have already covered it in quite a lot in part 5 of the “Leave Form Tribute” series). We can have a published InfoPath form connect to any SharePoint list or library across the entire farm to look up business logic details, such as an approver. This is something that SharePoint Designer workflows cannot do out of the box – it can only lookup from the site where the workflow has been created.

But, more important than that, we can easily use InfoPath rules and data validation functionality to ensure that the values are not null before submitting.

What this all means is that your SPD workflows end up being simpler and easier to maintain because InfoPath is providing all of the data to the workflow as well as the validation of the data. Therefore, the workflow now doesn’t have to do the lookup work and have unnecessary steps and actions.

For these reasons I think that, if you can, grab all of the data you need for a business process using the InfoPath form using hidden fields. Then publish the form and ensure these hidden fields are published as site columns.

For this particular purpose, I think that InfoPath is a lesser evil than SharePoint Designer workflows.

3. What are the pause actions there for anyway?

Finally, I promised I’d explain why I had a pause action in the workflow. This is to get around a race condition with workflows that produces an intermittent error message:

“This task is currently locked by a running workflow and cannot be edited”

I’ve seen this occur in several situations and it pretty much boils down to some workflow actions being synchronous and subsequent actions starting before the previous action properly completed. Consider this example.

One workflow creates or updates an item in a list, say a task list. But the task list also has a workflow attached to it. This means that the first workflow creates the task item and then moves onto the next step. Meanwhile, a new workflow has been triggered for that new task list item. This secondary workflow refers to information stored in the main item which causes the race condition.  If the information in the main item is not committed before this workflow attempts to use it, you’ll get null values when the main item is a new item.  When working with SPD workflows, these null values will show up as ????. 

To resolve the race condition, I had to ensure that the main item was committed before the secondary workflow was started by pausing the workflow.  Why does pausing the workflow cause the changes to be committed?  According to the MSDN article “How Windows SharePoint Services Processes Workflow Activities” http://msdn.microsoft.com/en-us/library/ms442249.aspx

Windows SharePoint Services runs the workflow until it reaches a point where it cannot proceed because it is waiting for some event to occur: for example, a user must designate a task as completed. Only at this "commit point" does Windows SharePoint Services commit the changes made in the previous Windows SharePoint Services-specific workflow activities…

The not-so-clever workaround is to pause the workflow in between actions. When you add a pause, the workflow “cannot proceed because it is waiting for some event to occur” and therefore makes it a commit point. Not pretty – but works.

I hope that you find this article of use in your SharePoint Designer workflow troubleshooting endeavours. Below, I have pasted the complete stack traces (for the search engines).

Thanks for reading

Paul Culmsee

                      

No Tags