Business stages functionality operates with business logic and allows building complex scenarios within deployed forms without workflow, like Nintex or SharePoint Designer. Knowing your business process is critical though.

Business process

Let’s review a simple case to understand the business stages logic. Imagine, we have a Request for access form. Students must fill in this form to request access for external visitors to their campus. There are some rules and requirements, like the form must be submitted at least 24 hours in advance of time requested. It must have a signature of the departmental head or chair, and be presented to the Security Office for approval.


We are going to build a scenario, where submitted form first checks the “24 hours” rule, then goes for signing to department chair or head and then goes for approval to Security Office. If the form content fits requirements, then the request is approved.

At this point it is clear that we need to have at least three stages for the request – Initial, Signing, and Security. At the Initial stage the form should be empty and new instance is created from the predefined content type by user request. Once the form is opened, it is automatically assigned to the Initial stage. When the form is submitted, it moves to the next stage – Signing. And then, when signed it goes to the Approval stage.

It is highly recommended to visualize business processes, even simple ones. It helps to determine what is missing, optimize steps and effectively share information with your coworkers. For the beginners I can recommend a free tool – yEd graph editor. Using this tool even SharePoint Designer Workflows can be visualized as simple diagrams.

Just a sample of business process visualization

Building rules

Let’s check how “24 hours rule” works. Being a part of approval procedure, this check could and should be performed even before the form is sent. Depending on corporate goals (e.g., do we need to know if someone tried to send a wrong request and collect such statistics?) we can check this on a client side and avoid incorrect data submission. Otherwise, we can check this on a server side – thus we can have all the student request information saved on the server (marketing guys would clearly like to have this option turned on).

In our case we are using a simple JavaScript on a client side and checking this rule right in a PDF form. The logic of rules for business stages is pretty simple and natural. When a new form instance is created, we know, it is in the Initial stage. We do not even need any rule, action or formula to set first stage to the Initial stage.

If the form has not been submitted, it also does not go to the next stage. So, same here – no change, no formula, no rule.

If the form is submitted, we can assume using our business process diagram that the form automatically goes to the Signing stage. So, using a rule we need to change form stage to “Signing”. Pretty easy, huh?


Switching stages

While waiting for signatures, form stays in the Signing stage. Or we can make it simpler, again to optimize process and increase personnel efficiency. We don’t need to wait for both signatures. So once someone signs the document it  passes the form to the next stage. All we need to do is to check if the document is signed… then we just change stage to Approval.

By checking the content of the related field on the next form submission we can make another decision and finalize the whole process.

Until you need to gather feedback, when you send emails, tasks and notifications, you can avoid using workflows! Using this simple approach and standard list events you can also send notifications on status change to every person, who is related to every next stage.

Of course business stages are not meant to replace workflows. This functionality extends your abilities, when you do not even plan to use workflows. Combine them both to achieve even greater degree of approval automation.

Leave a Reply

Your email address will not be published. Required fields are marked *