SharePoint Forms and Workflow – A Different Perspective
Whenever I get into conversations about forms in SharePoint (or anywhere else for that matter), the conversation almost always turns immediately for workflow. It seems to greatly surprise a lot of people when I say that sometimes workflow is irrelevant for forms. I’d say that 80%+ of SharePoint forms have no workflow at all. (I think it’s a higher percentage, but I know many of you live and die by workflow.)
I think forms and workflow are too often intertwined as concepts, making the forms discussion overly complex.
IMO, forms are for collecting or editing data. Workflows are for managing that data. By keeping those two concepts discrete, we can have excellent forms that just do what forms should do.
Conflating the two will probably delay the possibility of a robust new form tool for SharePoint. We know that something is coming to replace InfoPath, but we don’t know what it is yet.
We learned early in 2014 that InfoPath is dead. In actuality, it’s not dead; it’s only entered its twilight years. We have until 2023 before it isn’t “supported” anymore, and it will probably be useful for many people even after that. (I won’t make any snarky comments about “supported” software.)
I made up the 80% number above based on my own experience. It really depends on type of SharePoint installation you’re working in. My work is more toward the KM and Intranet side of things, and it’s very rare that I end up implementing a workflow. Knowledge workers can be trusted to do their work in the right way to create value, and it’s rarely a sequential or predictable thing. The few cases where workflows matter – time sheet submission, time off requests, article posting, etc. – the workflows tend to be very simple.
For similar reasons, I haven’t seen much need for InfoPath. With a little JavaScript and CSS, I can usually layer a veneer over the default list forms to give them any boost they need to meet business needs. Even so, the default list forms are fine probably 90%+ (another number I’m making up) of the time.
So much of this depends on the culture of the organization, too. If it’s an open and trusting culture, workflows come up infrequently. If it’s more of a command and control culture, they want workflows for everything. That is until you ask them to describe the repeatable process and they realize that there really isn’t one. Either they have to define a real process (lots of hard work) or they keep doing things the way they have – in a slightly disorganized way that still works.
My point is that assuming that there’s always a coupling of forms and workflow means that everything gets more complicated fast. I like the fact that forms and workflow are separate but connectable in SharePoint now. It means I can plug in a workflow if and when I need it; the forms engine isn’t too cluttered by the workflow artifacts.
What is your experience on this? Are forms and workflow always intertwined or are they really two separate ideas? I’ve created a little poll below to capture your feelings on this. Add your voice into the mix and I will try not to use the statistics inappropriately, as do may others.
[polldaddy poll=”8479060″]
When the business says they have a workflow what do they really mean? Are they talking about an approval process to get their data published in a verified and trusted format. Or are they talking about a versioning process to get change history in case they want to revert or use a previous version. These two scenarios are usually covered OTB by a SharePoint library. I’ve seen some complicated approval processes but it still boils down to someone or multiple someones approving the content.
I’m curious what other kind of workflows are being used.
Another thing that occurs to me, Brian, is that we probably have vocabulary problems. To me a form is the thing you fill out, not the resulting data. Many applications conflate *those* two concepts as well. A lot of the different views here could simply be a lack of consistent terminology. People may be saying the same thing and have it sound different and vice versa.
M.
I agree. People use words differently. Workflow to us is not workflow to a business user. Work flows through an organization constantly. SharePoint Workflow isn’t normally involved unless SharePoint Workflow advocates are! :)
I’ve implemented quite a few projects that were aided by SharePoint Workflow. At the same time, I found that many projects I was brought on to do workflow for benefited from other pieces than SharePoint Workflow. Versioning and approval handle some of those situations. Sometimes it was event handlers or search that kick in after the fact. SharePoint Workflow and Forms are not tied together nearly as closely as business workflow and forms.
Can i ask u the code of this form pls
I agree about the tendency for over-complication. When a customer puts out a request for a workflow, I first have the conversation about what they mean and what they’re trying to do. Most of the time an event receiver or something as simple as an alert with a link handles the business need. To the business, it’s a workflow. The solution in SharePoint can usually be something much more simplistic.
As for the InfoPath discussion, I’ve seen it heavily used due to the skillsets of the SharePoint folks building the solutions, myself included. I’ve not traditionally been proficient with JavaScript and jQuery, but am doing what I can in my free time to ramp up as much as possible to stay relevant in the field. InfoPath has just been an easy way to get a nice-looking form out there and some of the workflow can be handled by the form (change the form’s status, change the view, and provide a nice visual of the “state” of the form). I’ve had a lot of great experiences here, but the form itself can become unwieldy and tedious quickly as well. One change to the form’s schema and the whole thing becomes troublesome, sometimes taking several hours to update because one field has been changed.
My message to folks for the future-state of forms in InfoPath has been “it’ll still be around for a while, but it’s a good idea to start thinking of alternatives.” What’s the next-gen forms solution from Microsoft going to be? I don’t know. Microsoft may not even offer one. With tools like HTML, CSS, JavaScript, jQuery, Angular, Knockout, and so on, I don’t see why they’d really need to. If we use the technologies that are already in place, we’ll be able to build solutions and keep up with the world of web development that happens outside of SharePoint.
I think the Form and Workflow (SP Workflow) discussion comes directly from conversations with the customer about what they want to do.
Collect information, verify the information is correct, then set up approvals and record trails. That means Forms and Workflow. These types of work are very common for customers whose aim is to streamline people workflows and make the approval steps more automatic.
Collect information, verify the information is correct, give them different UI to update that information later. Summarize the information in some sort of aggregate reporting: That means Forms and Reports (or BI). These types of work are very common for customers who want top-down visibility into multiple processes, perhaps to identify errors or issues, and isn’t as interested in streamline people workflows.
Both type of work exist. And it depends on how things are introduced to a client – if you tell a client they can use workflow, they will ask for it. If you don’t mention it, then they don’t “need” it.
I needed a new option in the survey. My Forms have upwards of 20 workflows on them, and are triggered based on different approval stages in the form (they don’t run automatically) SPServices is great at starting workflows when the user clicks on something. Something I should have done a long time ago was to split the form up into different forms… One of these days I’ll figure out how to clean this up.
I have definitely over used workflows myself. Often a much more efficient and robust solution can be developed using Javascript and Web Services. For example, when a form is submitted, one wants other lists to be modified.
In my experience, the most common reason we need workflows is for automated emails that need to be sent. These emails can vary widely in purpose; they might serve as a reminder in a year to come back and review an item, or they could serve as a request to approve an item.
Even emails are sometimes over used. If we have a central dashboard where users know they need to come and look at tasks that have been assigned to them, then we don;t necessarily need emails, and thus workflows aren’t needed.
The best workflow I ever wrote was for the CFO of a large company that needed to approve requests, while he was on the road. The workflow I built used Nintex’s Lazy Approval feature, and allowed the CFO to respond to an email from his iPhone with a the key words: “Approve” or “Do Not PApprove.”
I totally agree with your point of using Javascript, HTML and CSS for developing robust solutions instead of going for Infopath. But when it comes to a bigger form with several stages of workflow is included, then it’s always save much time for us by using Infopath.
Otherwise using Javascript and WebServices instead of Infopath is really nice and we won’t have to struggle with the limitations associated with Infopath. Specially in Office 365.
Hi Marc,
I am looking for advice regarding the InfoPath form that is created for a workflow’s initiation form. I want to modify it to display a couple data fields from the current item on which the workflow was started. But there does not seem to be a direct way for the InfoPath form to reference the data of the current item at that point.
Someone suggested creating a data source to the list, and querying for the item whose ID matches the ID in the URL that called the workflow. I know the URL has this format:
https://SPdomain/site/_layouts/15/IniWrkflIP.aspx?List={e6c2cff3-c74b-4e4e-b8c6-f28cd129b010}&ID=38&ItemGuid={83C51320-E2F0-485F-BE7D-F3CC3DBB3946}&TemplateID={239b33fc-44b4-4baf-904d-178cdc897918}&Source=https%3A%2F%2FSPdomain%2Fsite%2FLists%2FViewname%2Easpx
However, I do not know how to get InfoPath to extract a parameter value from the URL. Any ideas?
Betty
Betty:
The ID of the item is in the Query String on the URL. In the link you posted, you’ll see ID=38. You can use SPGetQueryString in SPServices to parse out the Query String, among other methods.
M.