I am going to share configuration examples of Execute SQL and Web Request workflow actions for Office 365. The example I used is based on the previous post by Dan Stoll on Sign your name across my heart and my previous post on Extending Nintex Mobile Signature control to desktop/browser to demonstrate how the Nintex Signature Control example could be used for a Shipping or Delivery Order scenario of business process. I have simply modified the Title control to enable the barcode scanning feature, and renamed the label to Item ID as shown in the below setting of the Title (i.e. Single Line Textbox control).
The outcome of that is shown in the diagram below, which could be used as a Delivery Form to which a delivery man could use to scan the Bar code or QR Code of a parcel or item delivered, and get the consignee to sign the Delivery Form for confirming the parcel/items have been delivered.
Once the form data had been submitted and sync back to the Sharepoint on Office 365, a workflow will be triggered to send Delivery Tracking Status to inform delivery status over email and/or SMS. Two workflow actions will be used in this scenario to make the process complete:
Execute SQL action for querying the email and mobile number from SQL Server,
Web Request action for calling a web service provided by SMS Gateway service provide to send SMS message(s).
Here is how the Database table looks like, contains the Email and SMS registered for the Delivery Status Tracking purpose. The database in my example is in an on-premise environment, the Execute SQL will be querying from office 365 to the on-premise environment, you will need to make sure the SQL database server is reachable to your tenant from the cloud.
The “Send Delivery Tracking Status” workflow in my example starts with the Execute SQL action and its configuration as shown.
The Execute SQL asction required two mandatory parameters – Connection String and Query. For quick access to the returned results of the Query, you can specify a single column values you want to retrieve (i.e. specify in “Column to retrieve” parameter) from your Select statement, the values are saved to a collection variable (i.e. specified in “Retrieved column values” parameter – colEmail in my example). The parameter of “Results in XML” is used to store the returned results of the Query in array/collection of XML (i.e. I used colXML collection variable in my example to store the entire returned results from the SQL Statement).
The Web Request action in this example is necessary as we need to call a SMS Gateway function provided by third party to send SMS messages. The web service I used in my example is provided by Clickatell (i.e. www.clickatell.com) supports different Web API, one of them being SOAP API. As such I am using the Web Request action to call the SOAP web service for sending SMS message(s).
The WSDL Location provided by the service provider for accessing the web service is:
This is what we need for the URL value of the Web Request action, but without the ?wsdl at the end of the URL. That is only needed when getting the schema.
The Method we going to use will be SOAP 1.2 as this is a SOAP API with supports of SOAP 1.2 standard provided by the SMS service provider.
The following sample request body was given for sending SMS messages.
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://api.clickatell.com/soap/document_literal/webservice"> <SOAP-ENV:Body><ns1:sendmsg> <api_id>123456</api_id> <user>MyUserName</user> <password>MyPassword</password> <text>This is my message here!</text> <to>2799900001</to> <to>2799900002</to> </ns1:sendmsg> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
What we need is just to replace the parameter values and use it as the Body of the Web Request configuration as shown in the diagram below.
The completed workflow of my example is shown in the below workflow diagram, which performs two branches of State Machine,
State 1 is to send an Email, followed by
State 2 to send SMS via the Web Request action.
“Get Item from Collection” ① is to retrieve the first Email value from the collection variable of colEmail (i.e. retrieved values in the Execute SQL action), here is how the action is being configured. The Email value is stored in variable txtEmail in my case.
“Get Item from Collection” ②is to retrieve the first XML content from the XML collection (i.e. colXML collection variable), the result is stored in txtXML text variable, here shows how the action is being configured.
The above action will give us below XML that is stored in txtXML workflow variable.
“Query XML” ③is being configured to retrieve the Mobile number from the above XML content, and stored the value in txtMobile workflow variable.
That’s all we need to build a Delivery Form and Delivery Status Tracking Notification process. Hope this example gives a good reference on how the Execute SQL and Web Request actions of Nintex Workflow for Office 365 can be configured.
I have a partner asking how to bring the URL of an attachment from a list item to the task form, allowing the approver to click the url to open the attachment. I recalled something I have done before which I haven’t got a chance to blog it for sharing. So, here I am trying to extract part of the previously done workflow that is relevant for the objective of the discussed topic – “Assigning the attachment URL to a column of the same list item”.
1. In the solution, I have a list with a column named “PictureUrl” (i.e. Single line of text) as shown in below diagram (i.e. this column is what I will need to store the attachment URL).
2. Upon the form saved, a workflow will be triggered to perform series of actions, I am capturing only the main logic here that are relevant to the objective of updating the list item with the attachment Url. The workflow starts with the below actions and its respective configuration as shown in the table followed:
Workflow Action Configuration
3. The workflow is continued with the following actions and its’ respective configuration to kick start a loop for updating the URL to the list item properties:
Workflow Action Configuration
4. In the loop, the following action is called to get the attachment Url
Workflow Action Configuration
5. That follows with below actions to assign the URL to the defined “PictureUrl” column
Workflow Action Configuration
Note: Don’t worry about the Note and Picture columns here, what we need is just the PictureUrl to be assigned for the purpose of the discussed topic today.
6. Finally, the loop is ended with the following loop related actions
Workflow Action Configuration
That’s all we need to get the job done. Hope this helps for those who are looking for the same.
The outcome will be a form supporting the capturing and displaying of Signature on both Nintex Mobile or Desktop form. The Signature data is save as base64 image data in a multi-line of text list column (i.e. “Signature” in this case).
Here are the steps I followed:
1. Create a custom list for the purpose. We are going to have only two columns defined, one for the Title (i.e. Single line of text), and the second for Signature (i.e. Multiple line of text – Plain Text), as shown here
2. Customize the List Form with Nintex Form, as shown below. And don’t forget to also create a layout for Nintex Mobile Phone if you going enable the Signature capture on Nintex Mobile Application.
3. We going to set the Signature control with “Client ID JavaScript Name” (i.e. to “jsignature” in my example) as shown below, this is needed as we going to call JavaScript to get the Signature Data and assign it to the Signature Multi Line of Text Form Control.
4. For the “Save” button of the form, we going to set the “Client Clicked” event to call a JavaScript to assign the Signature data to the Signature form control. Below diagram shows the Button’s setting.
5. I have taken the JavaScript from Dan Stoll’s post Sign your name across my heart, and modified it to work with the jSignature library as shared in my previous post Embedding Signature Pad in Nintex Form, I have changed line 23rd to hide the signatureUI using the CSS instead, and line 38 and 39 to call the jSignature library’s Signature control to allow capturing of Signature on the if the form is edited in the desktop browser. The JavaScript function (i.e. setControlValue) is to be called by the Save button to set the Signature base64 data to the Signature (i.e. multi line of text) form control. And, don’t forget to also include the jSignature library as mentioned in my previous post Embedding Signature Pad in Nintex Form.
NWF$(document).ready(function() {
// Strings to be translated
var NoSignatureMessage = 'No signature';
var AddSignatureMessage = 'To add a signature please open this form in Nintex Mobile.';
// Find all the signature controls.
NWF$("div.nf-filler-control[data-controlname^='Signature']").add("div.nf-filler-control[data-controlname^='signature']").each(function () {
// Find the container element which houses the actual UI the user sees.
var signatureUI = NWF$(this).find("div.nf-filler-control-inner");
var signatureInputo365ViewMode = NWF$(signatureUI).find("div");
var signatureInputo365EditMode = NWF$(signatureUI).find("textarea");
var signatureInputOnPremBothModes = NWF$(signatureUI).find("input[type=text]");
var signatureContent;
// Get the actual base64 value of the signature.
if (signatureInputOnPremBothModes.length != 0)
signatureContent = signatureInputOnPremBothModes.val();
else
signatureContent = signatureInputo365ViewMode.html();
// Hide all existing Nintex Forms UI elements.
signatureUI.css('visibility', 'hidden');
// If not in edit mode then show image
if (signatureInputo365EditMode.length == 0 || NWF$(signatureInputOnPremBothModes).is(':disabled')) {
if (signatureContent != "") {
// Insert the signature image.
signatureUI.after("<img id='img' height='" + NWF$(this).height() + "' width='" + NWF$(this).width() + "' src='data:image/png;base64," + signatureContent + "' />");
} else {
// Insert a message saying no signature.
signatureUI.after('<div>' + NoSignatureMessage + '</div>');
}
}
else {
// Insert a message saying its not supported in browser.
signatureUI.after('<div id="signature"></dv>');
var sigdata = $('#signature').jSignature();
}
});
});
function setControlValue(){
var str = $('#signature').jSignature('getData');
NWF$('#'+jsignature).val(str.substr(str.indexOf(",") + 1));
}
6. With that, we are all done, the form is now capable of capturing and displaying of signature on both Nintex Mobile or Desktop form.
The intention of this write up is to demonstrate how to pass runtime function – (in Nintex Form calculated value control) – to JavaScript for setting controls’ value. It also features the following techniques for extending NINTEX Form capabilities:
Capturing of “Change” event from multiple editable controls (i.e. single line of text control) to trigger JavaScript function call
Using JavaScript to set form controls’ value (i.e. based on data captured during the form filling)
Using userProfileLookup runtime function to retrieve Sharepoint User Profile attributes (i.e. Distinguished Name in this example)
Hide a calculated value control in form with CSS Style
Regular Expression to extract different occurrences of OU in Distinguished Name
The outcome of this exercise is shown in the diagram below, where changes made to either Title or Requester field in the form causes the calculated value (i.e. circled in RED in the diagram) to call a custom defined JavaScript function (i.e. setControlValue function in this case) and pass the form’s runtime function (i.e. userProfileLookup – returns Requester’s Distinguished Name) value as parameter of the JavaScript’s function, setControlValue function is to set values of both OU1 and OU2 “single line of text” control as shown in the following diagram.
Here are the steps to reproduce the above described outcome:
1. Create a custom list (i.e. “Set Form Control Value” custom list in my example) with list columns as shown in following diagram
2. Using Nintex Form to customize the custom list’s form, Nintex Form designer drew the form as shown in the diagram below automatically based on the defined custom list’s columns.
3. As we are going to use JavaScript to set value for controls OU1 and OU2, with data from Title control and form runtime function, we will need to set the “Client ID javaScript Variable Name” for reference by JavaScript at the later stage. The following diagram shows how the Client ID JavaScript Variable Name is being set for “Title” control as “title” (i.e. case sensitive). We will need to repeat the same for the other two controls named – OU1 and OU2 with Client ID JavaScript Variable Name as “ou1” and “ou2” respectively.
4. Add a “Calculated Value” control to the bottom of the form as shown below
5. Edit the formula of the “Calculated Value” control – RequesterDN in my example with formula as shown in the diagram below. The runtime formula of userProfileLookup to lookup “SPS-DistinguishedName” from the Sharepoint’s User Profile of the “Requester“.
6. Define a custom JavaScript in the Form’s setting for setting values of OU1 and OU2 controls, with below JavaScript
function setControlValue(value){try { var ou1array = value.match(/^(?:.*?OU=){0}[^,]*[,](.*?)(?=,|$)/i); var ou2array = value.match(/^(?:.*?OU=){1}[^,]*[,](.*?)(?=,|$)/i); NWF$('#'+ou1).val(ou1array[1]); NWF$('#'+ou2).val(ou2array[1]);}catch(err){};return value;}
The custom JavaScript defined in the Form’s Setting window is show in the following diagram
7. As we have now defined the JavaScript function (i.e. setControlValue(value)), we’re going to make changes to the calculated value control (i.e. added in Step 4 above) to call the setControlValue and pass the userProfileLookup function as parameter to the JavaScript call. Here is how the modified Calculated Value control’s formula looks like. After that is done, you may proceed to publish the form for testing.
8. For the form testing purpose, I have to created different users with /or under different OU(s) as shown in my example in below diagram. I have created two users – “Sales Person 1” and “Sales Person 2” for testing purpose with respective Distinguished Name as below
CN=Sales Person 1,OU=Sales Office 1,OU=North Region,OU=Sales Organization,DC=crestan,DC=local
CN=Sales Person 2,OU=Sales Office 2,OU=North Region,OU=Sales Organization,DC=crestan,DC=local
9. With the form published, you may test the form by entering “Requester” field with the created user (i.e. Sales Person 1 in my example), the results are shown in following diagram with OU1 and OU2 set to the OU1 and OU2 of the Requester‘s Distinguished Name
10. Try making changes to both the Title and/or Requester field with different value, which will trigger the Calculated Value control to call the JavaScript function for resetting OU1 and OU2 value.
11. As we are using technique of Calculated Value to call get the Distinguished Name based on the Requester field value, and passed the runtime function lookup value to JavaScript function call, we would like to hide the Calculated Value control as it is not needed to the end users. One easy way of doing it is of course using the default control setting’s visible attribute to “No“, but you will then realized the control will also be totally hidden causing the desired functionality to fail. One work around is to use CSS to set the visibility to “hidden” but the control is actually available for the said purpose. In my example I have defined a CSS class as shown “.nf-form-footer“
with that, we can then set the Calculated Value control’s CSS Class to defined CSS Class (i.e. .nf-form-footer in my example) as shown below. If you noticed, I have added the Title control reference in front of the formula, which causes the Calculated Value being triggered when changes made to the Title field, and causes the calling of JavaScript to set controls’ value again.
Once done, publish the form and you will get the below sample outcome when tested. (Noticed that the Calculated Value control is now hidden from users)
I was asked by a partner recently on the availability of Signature pad in Nintex Form, and I am sharing how I did it using the jSignature library from jSignature. This is to demonstrate how to embed a Signature Pad in Nintex Form for Signature capture, store, and display using the said jSignature.min.js javascript library. The data of the signature is stored in a text field for redisplaying when the form is opened. What you will need is just the jSignature.min.js file to be uploaded to your site for later inclusion into your “Custom JavaScript Includes” of the Form, also don’t forget you will need the jQuery liabrary to be included as well if it is not already done for the site or site collection level.
The result of the steps here is shown in below screen captured – Nintex Form with Signature Pad for signature drawing capture,
For the purpose, i have created a simple Custom List on my Office 365 Sharepoint site environment, with only two columns – Title, and Signature (i.e. both are single line of text) to store the title of the signature, and the signature data respectively, here is how the custom list setting looks like
With the custom list created, I have then customized the form with Nintex Form as captured below. My form consists of only three fields (i.e. data controls) – one for Title, one Rich Text Control for the Signature Pad, and Single Line of Textbox to store the Signature.
Include the “Custom Javascript” and “Custom Javascript Includes” as shown below, i have downloaded and saved the “jSignature.min.js” library to the SiteAssets folder of my Sharepoint site.
The JavaScript is to initiate the Signature Pad for signature drawing, or to re-draw the Signature from the captured Signature data if the form is opened for viewing or editing,
NWF$(document).ready(function() { var savedSig = NWF$(‘#’+sig).val(); var sigdata = $(‘#signature’).jSignature(); if (savedSig != “”) { var dataurl=’data:’+ savedSig; sigdata.jSignature(‘importData’,dataurl); } })
The “Rich Text” control of the Nintex Form consists of only one line of HTML code “<div id=”signature”></div>“, here is how it looks like in the Control’s Setting
The “Single Line of Text Box” form control is configured as below, where I have inserted the “Client ID JavaScript variable name” as “sig” for the JavaScript references.
The form’s “Save” button is being configured as below to include the the following JavaScript (i.e. set the “Signature” control value with the Signature data when the form is being saved),
That’s all you need to embed a Signature Pad in Nintex Form. Publish the form, and you should get a Signature Pad where you can draw signature, save the Signature in the Custom list, and displaying the signature when the form is opened for viewing or editing.
Repeating Section of Nintex Form is always a popular topic among the communities. I was trying to help a partner looking into issues he encountered implementing the solution proposed by Ayman El-Hattab in his great post of Displaying Repeating Section Data in List Views, The Easy Way!, if you did a quick search, you may find many other great posts such as …
If you do not need the Repeating Section’s data to be transformed and saved into other formats for other purposes, here is my sharing on how show the Repeating Section as table in List View using the native Sharepoint feature – CSR (i.e. as such this solution will work only in Sharepoint 2013 on-prem or Office 365, or later if CSR is not to be replaced with others).
Create your Nintex Form and the required Repeating Section, connect the Repeating Section to Sharepoint Custom List’s Multiline Text column as shown in the diagram below:
You will need to make sure the list column is of type “Multiple line of text” with “Plain text” format configured as shown below
Create your list item using the published Nintex Form, the data of the repeating section will be saved to the linked column (i.e. in XML format), and here is how the view looks like
Create a Page two include the List View web part, for the purpose of making this simple, I will include the Script Editor to the same page for the CSR implementation (i.e. you may refer to Microsoft document on other CSR implementation approach using master page and so on.) Here is how the page looks like in my demo
Cut and paste the following code to the Script Editor’s snippet
<script type="text/javascript" src="/Nintex/SiteAssets/jquery-1.11.3.min.js"></script>
<script type="text/javascript">
SPClientTemplates.TemplateManager.RegisterTemplateOverrides({
Templates: {
Fields: {
'Inventory': {
'View': repeatingSectionViewTemplate
}
}
}
});
function repeatingSectionViewTemplate(ctx) {
var xml = ctx.CurrentItem["Inventory"];
var decodedxml = xml.DecodeXMLNotation();
var htm = "";
xmlDoc = $.parseXML( decodedxml );
$xml = $( xmlDoc );
$xml.find("Item").each(function() {
htm = htm + "<tr><td>" + $(this).find("Product").text() + "</td><td>" + $(this).find("Quantity").text() + "</td></tr>";
});
return "<table border='1'>" + htm +"</table>";
};
//Replaces html notation to their equivalent xml escape characters.
String.prototype.DecodeXMLNotation = function () {
var output = this;
if ($.trim(output) != "") {
output = output.replace(/'/g, "'").replace(/"/g, '"').replace(/>/g, '>').replace(/</g, '<').replace(/&/g, '&');
}
else {
output = "";
}
return output;
};
</script>
Saved the page and you should get the result on displaying the Repeating Section data in table format on the view, here is how it looks like
The key challenges I encountered for my test is on the XML string saved in the “Multiline of Text column” is presented with the original html notation which I will need to include the DecodeXMLNotation function to decode it before passing to the Jquery’s ParseXML function.
With the new Nintex Document Generation action in Nintex for Office 365, it is now possible to create an Excel Report from Sharepoint List items. With the output options of either its original format (i.e. Excel file in this case) or PDF in the defined destination of Sharepoint folder, you can then automate the generated report document for approval as usual in Nintex Workflow.
In the following diagram, I have my Expense home page consists of Expense Items (i.e. Customer List) and Create Expense Report query form. Create Expense Report Query form is a simple form one can use to specify report filter criterial (i.e. Title, Start Date and End Date, etc. of the items to be included in the excel report to be generated).
The Create Expense Report query form is nothing but just another custom list to trigger a Document Generation workflow (i.e. “Process Expense Report – Demo” workflow in this case) to export the filtered list items to an Excel document with the newly available Document Generation workflow action. Here is a screen capture of the created Expense Report Query custom list. The “Process Expense Report – Demo” workflow will be triggered when new item (i.e. “KK Expense Claim for Dec” item in this example) being created.
Once the “Process Expense Report – Demo” workflow is being executed, it will generate an Excel document and output the file to the defined destination folder (i.e. Expense Reports in my scenario) as shown in the diagram below
The output of the Excel file (i.e. “KK Expense Claim for Dec – (Demo)” is shown below.
The “Process Expense Report – Demo” workflow is basically a 7 steps workflow made up of 13 workflow actions as shown in the workflow diagram below
Steps
Workflow Actions
What it does…
1
Action ①
Query List (i.e.Expense Items custom list) returned a list of items stored in list items collection
2
Action ②
Set the Variable idx to 0
3
Action ③
Loop through the list item collection to..
4
Action ④-⑨
Create dictionary pair of key (i.e. Field Name), and Value (i.e. Field Value). The dictionary has 7 pairs of 7 fields of expense list item to be built.
5
Action ⑩
Build a dictionary (i.e. dicItem dictionary) of the Expense list item (i.e. itemNo, itemExpType, itemDate, itemCurrency, itemAmount, itemAmountInSG).
6
Action ⑪
Add the list item dictionary (i.e. dicItem) to a new Expense collection (i.e. collExpenses)
7
Action ⑫
With the Expense Collection (i.e. collExpenses) as input, the Doc Gen action will used the “Expense Form – DEMO.xlsx” document template to generate “KK Expense Claim – Dec (Demo).xlsx” excel documents
Here is how I visualized the outcome of the built Collection “collExpenses” done by “Action 11” after completing the “Action 3” for-each loop.
Document Generation Action uses the “Expense Form – DEMO.xlsx” as template, and generate the Excel document which was then placed in the “Expense Reports” SharePoint Document Library. Diagram below highlights how the “Expense Form – Demo.xlsx” template is being “Tagged” in my example for Document Generation action to insert values into it.
The configuration of the Document Generation should be straight forward, here is the configuration of my example
The key challenges for my first time testing getting the Document Generation to work for creating the “Row Replication”, would be surrounding the building of “collExpenses” collection and Tagging the excel template for the repeating row purposes. Thanks to @Dan Stoll‘s hint on how to create the collection to be used as variable by the Document Generation action (i.e. Dan’s blog on that could be found here -> It’s here… Nintex Document Generation . With this blog, I am hoping it will help those who encountered the same challenges as me.
Nintex Workflow allows integration with external systems in many ways, it could be using Call Web Service action, Execute SQL action, Query BCS, Nintex connector actions, etc. Nintex Connector actions (e.g. Salesforce or Dynamics CRM actions) when put in a workflow, allows the workflow designer to not have to think about how to talk to the external system.
The Challenges
What do I mean by “not have to think about how to talk to the external system“? Let us take a look at if the Execute SQL action is to be used for the purpose, the workflow designer will need to know how to define connection string and SQL Query in order to use the Execute SQL action. That required the knowledge on Database Server source, Database, Table, Columns, etc. to be queried. As these are low level schemas of the external system, usually one will need to manipulate the data to get the expected result.
Similar to the Web Service request, the workflow designer will need to know the destination web service URL, method(s) to call, etc. or to translate the business process language into low lever programming concept and will need to understand the object models that sit between the two system in order to integrate with external system. The scenario of having the middle-man objects is illustrated in the scenario below where the Business Process designer will need to understand the middle-man “lead/leads” objects are sitting in between the Nintex and external system:
It is indeed challenging for Business Users to model a workflow themselves, as they are not programmer or IT personnel who knows the low level schema or object models of an external system(s). This creates an even challenging situation when more and more business processes will need to integrate with external system which requires more and more “objects” in between the systems.
The Connector Solution
The solution presented in Nintex for integrating with external system via “Connectors” is a more direct and straight forward approach, allows the Workflow designer to integrate with external system without the need to understand the low level schema or the object models of the remote system. It could be as simple as providing the pre-configured connection and “lead/leads” details for creating “lead/leads” in Salesforce system, etc., as illustrated in the scenario below.
Below list the currently supported connectors by Nintex workflow (i.e. both Nintex connectors and connector provided by Nintex vendors:
The number of connectors are growing from time to time, and in most cases, Nintex partners or customers with the Nintex SDK provided by Nintex will be able create connectors that are not available or open for use as generic connectors to customers’ environment.
The UDA solution
Besides connectors, one of the best practices promoted by Nintex is for expert/professional workflow designer to define UDA (A.K.A User Defined Actions). UDA is reusable action or wrapping of actions to work as connector, but without the need to program or coding using Nintex SDK. UDA to be called or used by Business Process designer without the need to understand low level calls to external system. The diagram below depicts a sample UDA design which calls web service to an external system, the UDA is packaged and to be used by other Business Process design by simple providing required parameters and expecting a retuned results by the UDA.
The following diagram demonstrates how a Business Process Designer model a business process workflow by calling the above “Get Leave Balance” UDA sample, by passing the required parameters that is Employee ID and Leave Type. The UDA (i.e. Get Leave Balance UDA in this example) will return the Leave Balance as expected to be used as leave calculation to be used in this scenario.
I was asked a lot in the past, since in Sharepoint by default supports creation of workflows to support business process automation, why is there a need to consider Nintex Workflow? In this write up, I am trying to revisit the approaches and steps involved in Sharepoint workflows. With the summary on that, I am hoping to identify key challenges one might face, or benefits one could get if Nintex is in place for the same purpose.
I was asked a lot in the past, since in Sharepoint by default supports creation of workflows to support business process automation, why is there a need to consider Nintex Workflow? In this write up, I am trying to revisit the approaches and steps involved in Sharepoint workflows. With the summary on that, I am hoping to identify key challenges one might face, or benefits one could get if Nintex is in place for the same purpose.
Let’s revisit the approaches in implementing workflow in default Sharepoint environment. To simplify, I grouped the approaches into three as summarized in the table below:
Approach
Description
Tool
Out-of-the-box (OOB)Workflows
Automate common business tasks such as getting approval or collecting feedback on documents
Within Sharepoint environment via browser
Custom Workflows
Define from scratch with customer business process logic or states. Opportunity to assign own workflow actions that are made available default Sharepoint installation
Sharepoint Designer
Custom Workflows with customer actions/activities
In the event if the default workflow actions do not fulfilled the business process steps requirement. Programmers can encapsulate customer code in new actions.
Visual Studio
Out-of-the-box Workflows
OOB workflows are pre-programmed workflows that are included in Sharepoint, OOB workflows are template driven workflows allowing one to select options with the initiation form when adding the workflow to list or library in a Sharepoint site. Different version of Sharepoint comes with different set of OOB workflows, Sharepoint 2013 come with – Approval, Collect Feedback, Collect Signatures, Disposition Approval, and Three-State OOB workflows. Here is the link to anOverview of workflows included with Sharepoint provided by Microsoft.
Adding a OOB workflow to a list or library can be achieved by just select the “Add a Workflow” from the list or library’s “Workflow Settings” menu in the Ribbon menu. The “Add a workflow” configuration page will be presented allowing one to select a OOB workflow and other configuration values. This is illustrated in the diagram below,
The steps usually involved with an initiation form allow additional assignment of required parameters such as Approvers to be used for the workflow to send or assign a task to. This is illustrated in the diagram below.
OOB Workflows – Key Challenges
OOB Workflows provide a great way to business users for automating business tasks that are seen commonly across different organizations, these are processes such as getting an approval, sharing and collecting feedback on documents. Unfortunately, when it comes to actual implementation, the majority of the time we will need to do more than just getting an approval or changing the status of the document from “Under review” to “Approved”. Most of the time we would need additional tasks to be accomplished such as:
Sending a notification to the initiator when the item is being assigned to someone for approval
Copying the document to a destination repository when it was approved or final
Etc.
You will realize too, you will need to hard code the “Reviewers” in the above “Approval” workflow sample by selecting a person whom you want the document to be assigned to. This could cause a huge maintenance issue or effort if the approver left the organization or switches roles, which happens very often in today’s business environment.
Due to this, I find a lot of time we would need to use a Custom Workflow instead of the OOB Workflow that comes with Sharepoint, as it allows us to add own workflow action(s) or steps according to the need for a business process.
Custom Workflow
The second approach for workflow implementation in Sharepoint is the Custom Workflow, which gives us the flexibility to define the steps needed for a business process automation. Sharepoint comes with a set of out-of-the-box Workflow Actions to support the common business process automation. The following is a grouped list of Actions available in the default Sharepoint 2013 installation.
Core ActionsAdd a CommentAdd Time to DateDo CalculationLog to History ListPause for DurationPause until DateSend an EmailSet Time Portion of Date/Time FieldSet Workflow StatusSet Workflow VariableStop WorkflowDocument Set Actions (not available in SharePoint Foundation)Capture a version of the Document SetSend Document Set to RepositorySet Content Approval Status for the Document SetStart Document Set Approval ProcessList ActionsCheck In ItemCheck Out ItemCopy List ItemCreate List ItemDeclare RecordDelete ItemDiscard Check Out ItemSet Content Approval StatusSet Field in Current ItemUndeclare Record (not available in SharePoint Foundation)Update List ItemWait for Field Change in Current ItemRelational Actions (not available in SharePoint Foundation)Lookup Manager for a UserTask ActionsAssign a Form to a GroupAssign a To-do ItemCollect Data from a UserStart Approval Process (not available in SharePoint Foundation)Start Feedback Process (not available in SharePoint Foundation)Utility ActionsExtract Substring from End of StringExtract Substring from Index of StringExtract Substring from Start of StringExtract Substring of String from Index with LengthFind Interval Between Dates
The process involved in implementing a Custom Workflow in Sharepoint can be summarized in the below sequence:
1. Authoring and Deploying a workflow
Defining the process by adding Stages/Steps, Workflow actions, activities, and conditions. Once a Workflow is defined, it will be deployed to Sharepoint as a workflow template available for associating to the list or libraries.
2. Associating a Workflow
A Workflow Template is to be attached/associated to Sharepoint list or content type before in instance can be created or executed.
3. Instantiating a Workflow
Workflow is being executed or instantiated either by manual triggered or when an item is being created or changed.
The designing or authoring of a Custom Workflow has to be done using the Sharepoint Designer IF and ONLY IF encapsulation or coding new Actions is not required to fulfill the business process automation. In the event of new actions being created for the workflow authoring purpose, the programmer will need to create the custom action(s) using Visual Studio for the purpose.
Creating a workflow by using Sharepoint Designer 2013 can be found in the Microsoft MSDN site, details how to install, open, and create a workflow by using SharePoint Designer 2013 and the SharePoint 2013 Workflow platform. In summary it involves steps to
Install Sharepoint Designer (i.e. if it has not been installed in your Sharepoint environment)
Open or connect to a Sharepoint site in the Sharepoint Designer
Creating workflow in the Sharepoint Designer for a Sharepoint environment
The key activities involve in creating a workflow using Sharepoint Designer covers add Actions, Conditions, Stages, Steps, and Loops to build your workflow. These workflow components are available in the ribbon of SharePoint Designer 2013, as shown in the following figure
Custom Workflow – Key Challenges
The Sharepoint Designer extends the capability not just to create Custom Workflow in supporting business process automation, it also provides other functionalities to support Sharepoint site customization such as Page Layout or Page authoring, etc. Unfortunately, when looking at just creating Custom Workflow, the following drawbacks are the key challenges most users find:
Sharepoint Designer is seen as a designer tool in general Sharepoint site customization instead of just focusing for Workflow development or designing purpose.
The business process owner or designer will need to install Sharepoint Designer to design Custom Workflow
By default the Sharepoint Designer supports only the authoring of workflow in a declarative rules-based and text definition/statements, which is not “flowchart” graphical design experience. “Flowchart” style is only available since Sharepoint Designer 2013 but being supported by additional Visio application that will need to be installed separately.
The need to install additional software(s) to support the Custom Workflow is one key challenges. But the actual issue with workflow implementations is the lack of Workflow Actions supporting the business process automation. Majority of time, when you are creating a Custom Workflow, the default out-of-the-box Workflow Actions (i.e. less than 40 as listed in the previous paragraph) are not sufficient to fulfill the requirement of business process automation, and then IT programmers are loaded with the efforts to program custom actions using Visual Studio.
Nintex Workflow advantages
Just to highlight a few, here is how Nintex Workflow for Sharepoint helps in supporting the workflow design process:
Business Process owner or developer can now accomplish the Custom Workflow design process without leaving the Sharepoint environment (i.e. within the browser environment).
Nintex Workflow designer supports the workflow design process in a quick and easy manner.
Nintex Workflow designer is embedded into a Sharepoint site, without the need for workflow developer or process owner to install additional software to design workflow.
Nintex Workflow comes with over 160 default workflow actions to support business process automation, and additional actions can be downloaded from the online “Catalog” (i.e. Nintex store).
Nintex Workflow encourages no custom coding of custom actions required, this is achieved with the rich set of Workflow Actions that come with Nintex Workflow installation. In the event that a custom action coding is needed, the SDK provided allows programmers to develop custom actions.
The workflow design in a “flowchart” graphical format provides self-explanatory to business users, and reduces tremendous maintenance efforts when it come to changes to the business processes.
