Here's mine for SharePoint on-prem.

You know how it's really useful to graphically check a workflow status?  Well sometimes you don't want to show all the actions in the workflow.  e.g. you only want to show the core stages so you hide items such as logging, setting variables etc.

Just go to the action, click on the common button and tick "Hide from workflow status"

Cheers,

Chris

Here's mine for Nintex Workflow

Make use of comments. Processes will change and so workflows have to change too. Even if you think you understand your workflow now, you will thank yourself if you have to come back to the workflow after a process changes.

I try to ask myself: If I had to come back to this workflow in half a year, what might I find helpful?

and here is mine for Nintex Forms:

- Rename your rules! if you have to find a rules and you don't know the controls that it's applied to, you have to check the show all checkbox and then, if all the rules are named Rule 1, Rule 2, ... you don't have any clue on how to find your rule except from looking at each of them. With your naming convention (and also looking at the icon to distinguish between formatting and validation rules), it's much more easier

Giacomo

Coming from SPD workflows I might log to history a little too much!

Within my log to history action I number them sequentially left label: logX It would be good if it happened automatically.

My top line within the log to history action would be

***log1***

logtext, variable output result etc.

I find it easier to read the workflow history that way.

My top tip certainly when starting out is to complete each field within a control that you can, not what is only needed to complete a job/action.

i.e. for each loop, don't just fill out the options : Target collection and Store result in: Also complete Index and stop processing.

If a control has an error handling option, complete that too.

I think this is really helping me learn more about a control, its function and also by trying to figure out what a control and what a specific field does, you're learning more - holistically. It helps troubleshooting too and I think it may be a way to build your own best practice notes too.

My tip is for using the Workflow Editor's Query List action

Most examples will have you using the List ID / GUID, which is the SharePoint internal identifier for any particular List. However, I found out the hard way that this will break in the event that you migrate things from one SharePoint to another, resulting in several helpless and broken workflows . 

Despite that, I found that you could actually just use the List Title outright in your CAML Query, without the guid, which is a LOT easier and infinitely more convenient. 

<Query>
  <Lists>
    <List Title="Your List Title" />
  </Lists>
  <ViewFields>
    <FieldRef Name="Title"/>
  </ViewFields>
  <Where>
    <Eq>
      <FieldRef Name="ID"  />
      <Value Type="Number">{ItemProperty:Some_x0020_Field}</Value>
    </Eq>
  </Where>
</Query>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Maybe this is well known, but it was certainly a lesson learned for me! 

Here is my Nintex Workflow quick tip... I like to use an "Action set" to break up complex workflows into smaller sub-parts. That way, I can collapse them to give myself more real-estate on the screen and troubleshoot issues without a lot of non-related actions visible. Just be aware, if you use action sets as to provide elevated permissions to a group of actions, that feature will not be available in an action set that is nested inside of another action set.

I'll give some top few that I use for most apps I build.

• Use a configuration list. This allows manipulation of workflows while in flight, no need to republish workflows if there is a value change. Like an approver.
• Use separate auditing lists to store key points of history for a process. DO NOT rely on workflow history alone.
• Use Help DOCUMENTATION. It's really a great resource! Whether it's in the designer help or using help.nintex.com. There are very useful tips and concepts in the documentation, not only action descriptions. I reference help personally quite often. It's easier to memorize where to find information than memorizing all the information.
• Use State Machines. They are like having a Force power. Trust me you will. Easy way to restart processes at a specific point. 
• Use Bookmarks in the community. Sometimes I read blogs and get very excited about new features or scenarios, but I can't implement them right away. Bookmarks have made it very easy to relocate those treasures when the time arrives!

Andrew,

Just so I understand:

Configuration list - is that having a second list i.e roles per office. i.e. I have multiple offices locations and each office has an HR person, IT person etc. You reference this list of people. I've done that in SPD workflows and works a treat.

Can you demo how you use an auditing list- that's something I've not done. I do rely on workflow history.

Thanks

A

Yes, create a separate list that uses key value pairs. I use lists with at least three to four fields. The title field is the key, then a person group typed field, a single line of text, and a multi line text for the value fields. See a write up here  

On an auditing list, create a list where in your workflow you use a UDA or simple Create Item action that saves relevant data to a list. Data like, workflow name, site url, task name, approver name, outcome, etc. You use these fields and create a new list item each time you need to track data long term. You don't have to use all the fields, for example, just use the task related fields when saving task information. An example of this concept can also be seen in Nintex Project Server workflows Using Nintex Event-Driven Workflows to build an Audit Log for Project Server Changes  

Thanks, I'll check out the links

Much appreciated.

My tip for today: Bookmark this page ;-)

This also helps prevent flooding the WorkflowProgress database table and the subsequent timeout failures on weak hardware.

In a workflow using Nintex Forms same form is often used in all tasks. Therefore I create the form in a FlexiTask action and then I copy this action when I need a new Task. Copied actions are using same form, so modifications need to be made only once.

My tip: Give XML-friendly names (Latin only, no spaces, etc.) to form controls from the start so that you can easilty figure out what's going on in the FormData field if anything goes wrong with bindings.

For Nintex Forms: Try to always use panels when hiding/showing controls and implementing rules. It makes the form resizing so much better. If you don't use a panel, some weird shifting can happen.

For Nintex Workflow: Being diligent with your logs is great, and so is the "change workflow status" action! Displaying that in your view can make your life easier in being able to quickly go to the logs of the active (or most recent) workflow and see at a glance where every one is.

Hi All.

Here's my quick top tip.

We have a document management system where document owners are sent a notification after a specified amount of time. Anywhere up to 3 years!! What are the chances of the owner still working for the company.......???

The way I found to get around this is to use a set a condition action where the condition is set to "Person is a valid SharePoint User". I get the Document Owner and set this to a variable of vPPLOwner. Evaluate this variable to check if the person is a valid SharePoint user. If Yes, send the notification to the user. If No, send the notification to the Owners group of the site (hopefully kept more up to date with valid users!!!)

This way the workflow will continue and the Owners can re-assign the document to a different owner and the review cycle will continue when that document is up for review.

Brilliant, why have I never thought about doing this before - doh!

***update***

Just done this as a test and so that I could create a snippet and use it in an existing workflow.

This is most likely my environment. Yet I had valid SP users, but they are disabled in Active Directory.

I know some users will have their email forwarded and some not (not sure why else they would be valid, but hey ho).

Yet for me a disabled AD account is perhaps more accurate:

Firstly I need the account name from my people picker control - I have to strip out various random characters and domain so I'm left with an AD account name

Query LDAP for above - userAccountControl

Set condition based on userAccountControl value next

Hope that helps somebody else.

Having only recently discovered this thanks to Marian Hatala‌ I would like everyone to know about parselookup in Nintex Forms which allows you to manipulate the output of ID;#Value:

top highlight is expression: 

middle highlight is expression: 

bottom highlight is expression: 

‌, this need not be reliable either!

if you run sharepoint with multiple languages/locales, title might be different for every language.

it's even worse in that case since it breaks application functionality (list is not found by title at all)

Cassy Freeman‌, that's too easy with single lookup

what about to parse set of lookups in one go

An actual blog post on this would be GREAT as it would be more easily searchable. Great stuff ‌ and ‌!

My top tip is something that I'll be implementing henceforth:

When creating a Nintex workflow for a team of users who are not Nintex savvy and maybe will just be troubleshooting as they go, use a "Settings" list to encapsulate as MUCH of that workflow's variables as you can. 

Need an email address for a notification? They want it to go to Jenny in Accounting? Great, create a list lookup for "AccountingEmail" and put jenny@accounting.com -- so they can update it without ever going into the actual workflow. 

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.

Basically anything you can do so that your users can change the workflow without going into it ... A+++.

Hahahah, cheeky  

Crap. I wrote mine and then came back and and it's the same as your first one. 

Use the 'Office 365 search query' action to collect data from many subsites. I recently had a challenge in O365, and this action just made my day.