My top tip is similar. Use those Labels. The more information you place in them, the more time you save yourself when building, testing, and updating workflows. Then you don't have to open the Action to know what it does.
With such a great and easy to use product, its easy to rush in and start developing without giving things much thought. My tip is: think through your project, consider the environment to know your limits, make sure you understand the business problem you are solving, architect the workflow to know how it will flow, and understand security and other business restraints. In other words, do a bit of planning, to save a lot of time not having to redo things. There have been countless times when someone develops a linear workflow, only to realize a state machine would have been much more appropriate. Do this and you'll have a much better chance at getting it right the first time.
Thanks
-Mike
I've done this and it makes life so much easier! If someone goes on vacation, they can just update the list and I don't have to touch the workflow.
So many things have already been stated, but I'll mention a few simple things that have made my life easier. In Nintex Forms, use panels for groups of fields and make sure you name your panel so you can easily find it when viewing all controls in use. When creating a workflow, re-name your actions so that you (or someone else) can tell exactly what the workflow is doing by the names of actions.
When using the Query List action, if you expect more than one item to be returned from the query, go ahead and populate the column values you want to collect in separate collection variables within the query. It will save you from having to re-query the list for each column value you need for each individual item and will reduce round trips to the database to retrieve the data (improves efficiency):
Remember to create a "counter" variable so keep track of where you are in the collection variables.
Here's a Reminder about Workflow History lists:
- If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as ‘Log to History List’ as they can quickly fill a workflow history list if left unchecked.
- Utilize the History list during the development and testing stages of your workflow and remove or disable them prior to production release.
(https://community.nintex.com/community/build-your-own/blog/2014/10/13/defensive-workflow-design-part-1-workflow-history-lists)
The same goes for multiple notification bodies - have an email wording that fits into multiple emails? (Or, even just one?) Put that in your settings list as well -- users can update that.
I love this....the only thing is we put a lot of list item info in our emails, typically, so we could at least have them edit the "intro" bit.....this seems interesting.
As in, we could put in the WF:
Hello [[User]],
[[Email Fluff]]
The details are as follows:
Thing: [[Thing]]
Stuff: [[Stuff]]
And the end users could edit [[Email Fluff]] in the "settings" list!
Ohh, I've done this. My problem is, even when I plan, I come up with like 3 valid ways of executing something and only realize part way through why the one I picked is subpar :I I suppose better planning comes with experience!
My top tip - remember use Commit Pending Changes at the appropriate place to make sure your workflow step finishes writing to an item before another step attempts to read from it.
Hopefully most of you already know that. In that case, I will add this extra tip that I found when reviewing our own workflows. I did not write this workflow, but I thought it was neat that it can set up an Outlook meeting to a shared calendar. It appears to use "Exchange Impersontation" as described here,
https://msdn.microsoft.com/en-us/library/office/dn722379(v=exchg.150).aspx
The workflow reads to see if a "SendToOutlook" column is set to Yes or No. If Yes, it sets workflow variables such as Message, Email, etc. It then performs a Web Request which is set up like this
URL = your Exchange.asmx location
Username & Password = an account that is created to access that calendar.
Select "SOAP 1.1"
Here is the SOAP code:
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Body>
<CreateItem xmlns="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"
SendMeetingInvitations="SendToAllAndSaveCopy" >
<SavedItemFolderId>
<t:DistinguishedFolderId Id="calendar"/>
</SavedItemFolderId>
<Items>
<t:CalendarItem xmlns="http://schemas.microsoft.com/exchange/services/2006/types">
<Subject>{WorkflowVariable:Title}</Subject>
<Body BodyType="Text">{WorkflowVariable:Message}</Body>
<ReminderIsSet>true</ReminderIsSet>
<ReminderMinutesBeforeStart>60</ReminderMinutesBeforeStart>
<Start>{WorkflowVariable:StartString}</Start>
<End>{WorkflowVariable:EndString}</End>
<IsAllDayEvent>false</IsAllDayEvent>
<LegacyFreeBusyStatus>Busy</LegacyFreeBusyStatus>
<Location>My Desk</Location>
<RequiredAttendees>
<Attendee>
<Mailbox>
<EmailAddress>{WorkflowVariable:Email}</EmailAddress>
</Mailbox>
</Attendee>
</RequiredAttendees>
</t:CalendarItem>
</Items>
</CreateItem>
</soap:Body>
</soap:Envelope>
To finish, it updates the item to set the "SendToOutlook" column to No.
This is a great way to move larger pieces of the process around as well. Put everything into an Action Set and then you can grab the single action and drag it to where you want to place it!
This is the one tip I tell everyone when it comes to Nitnex Workflow and Form development; replace what you have, the improvements will come naturally.
All too often we rush into a project with wild ideas on how to improve an existing form or process, but rarely do we take the time to understand how and why it is the way it is currently. This is along the same lines at what mentioned above; you have to take the time to plan out what you are going to do. I approach everything as a conversion from "X" to Nintex. From there, we can quickly identify improvements and issues that may arise. Since we are approaching the development with how the current form or process is built, we gain the knowledge that was poured into already. We can learn from other's mistakes and understand how they overcame issues that came up (and we will most likely face as well).
Nintex gives us speed to market already, but speed to market is only as good as the product that you are putting out. If you rush through it and do not capture all that is required for the process or form, you are going to doing a lot of re-work.
My top tips would be; get involved in the community, and don't be afraid to ask questions. I come here daily to find answers. I do know what I would do without the Nintex community.
I wanna go completely opposite on you , use "Message to log on completion" which exists for most actions...
I used log in history a lot, but the "bad habit" was to forget and remove these as my workflows went into production or I debugged my workflow. Log in history is great, and somewhat needed if you need before and after values, but "Message to log..." get the job done and keeps down the number tasks in a single workflow.... :-)
For clarification, this is what was referring to in the first point of his post too, so this expands a little further on it.
I refer to them as "Configuration Lists". The .NET developer in me likes to call everything I create in Nintex, an application. As a result, applications have configuration menus for the future administrators of the app to manipulate as needed rather than hard coding them into a workflow or form which would require the developer to change them.
My tip is more of a generic development tip, but applies more to working with SharePoint and Nintex.
Be aware of limitations before starting work.
This involves understanding the potential scope of the application you are working on, not just what the customer expects it to be when it goes live. So you want to consider list thresholds, form limitations and how it impacts performance (i.e. many repeating sections with lookups in them etc, how will the form perform if a user adds 100 sections???).
Only if you're aware of limitations and performance impacting designs, can you give the customer realistic expectations of the end product.
If they want all that complicated design in there, it will come at a performance cost, are they willing to live with that?
Nintex workflow: When creating a new item, use the "Store new item ID in" field to store the ID in a variable to use later in the workflow. This variable must be an "Integer" in order for it to appear in the "Store new item ID in" drop down. (Note this option has always been in SharePoint Designer, not just Nintex).
So, instead of 3 actions, you only need 1:
I've seen the above used in workflows I've inherited. Note: you may still need the "commit pending changes" depending on what you are using the new ID for (eg. if you're just building a link in a notification email, it's not necessary).
My Top Tip would be :
Use "Nintex Forms Rules" to set the column as mandatory rather than setting it up from SharePoint column settings.
In this way you end up managing a single source (Nintex form) rather than both SharePoint and Nintex
I love this idea! My pro tip is for Document Generation:
Always keep formatting on when creating your template, this will really help you debug any weird formatting that may happen after data is merged into the document.
I know I already posted a tip in here but I just remembered one tip that was a HUGE time saver for me when I was just getting started in Nintex Workflow.
Go into the workflow and craft a great email layout. Get it looking just like you want with all of the formatting bells and whistles. Then, while your cursor is in the body section of the email, from the "FORMAT TEXT" ribbon, select "Edit Source". There you will see the HTML of your email. Copy this and save it in a .txt file for later use. You can go back and use this as a starting point to build your emails in the future giving a sense of uniformity to your workflow communications without all of the manual formatting. You will of course have to adjust context and content for each email down the road but the templated html you saved will give you a great place to start.
Great points Ryan Greenaway – along a similar thread, my top tip would be to thrash early.
Here’s what happens on almost every software project. Someone comes up with a software idea to make. They hire programmers and they start building it. Then about three months before the project ships, other people start to get involved. Other people want to look at the UI. Other people start weighing in. About two months before it ships, thrashing occurs, people start pulling things out, and putting things in. And the closer you get to deadline, the more thrashing occurs. The more cycles get extended, the more work gets put into it. Until eventually you ship not on time and not on budget. What smart programming shops like Microsoft have adopted, is that they must thrash in the beginning, when it’s cheap and easy. They insist on thrashing early. Because they know their job is to ship. – Seth Godin
In my mind, one of Nintex's most valuable asset's is it's low cost to change (both in terms of dollars and time). Take advantage of this as a workflow/forms designer! Prototype early and mitigate as much risk as possible with a given project. Evaluating platform limitations (on-prem vs. O365) and quickly building out proof-of-concepts for sake of gathering early feedback can do wonders for you and your customer.
Every business process has it's own dose of complexity and targeting these areas up front can be pivotal to making wise design/architecture decisions.
For Nintex Workflow, use Workflow Constants whenever possible. In particular, using the Credential type is a great practice and huge time saver. Designers can securely save a username and password combination that can be used in workflow actions that require credentials. If the account password changes, it can be updated quickly in one place instead of having to update it in multiple actions in multiple workflows. Designers can also wrap permissions around Workflow Constants, allowing only specified users and groups to see and use them when designing a workflow.
NOTE: Unfortunately Workflow Constants only exist in Nintex Workflow on premise. This functionality does not exist in Nintex Workflow for Office 365 at the time of this post.
Cassy Freeman I can't agree more with the reminder to leverage the "Log to history list" action.
Now that the "disable action" functionality is supported on-prem and on O365, it's always wise to give yourself additional context in the log for troubleshooting. Even if these entries are intended for the workflow designer (not end users) the disable action functionality is a nice clean way to preserve your testing harness when moving to production.
For me is a good practice to do it every day >>>
Thanks ! Considering limitations, when I first got Nintex workflows, we had a doozie of a time figuring out a phantom issue that ended up being the size limitation of a SharePoint workflow. I think it is roughly anything aver .5-.6 MB will start to behave inconsistently odd. It seemed that the errors were never the same and never failed on the same actions. It would have saved me about 6 weeks of pain if I had known the limitations.
That might be a great post/thread/mission... come up with a limitation with SharePoint and or Nintex that users need to be aware of with a list of issues that ensue. Sort of a "best practices" from another perspective.
