Five Nintex K2 fixes your team can make without raising a ticket

Some K2 problems look far more serious than they are. K2 rarely tells you what has actually gone wrong, so a fix that takes under a minute can cost you an afternoon of looking. These five are written for K2 administrators and the people running workflows day to day. Nothing here needs server access or a support ticket.

If your organisation runs Nintex K2, the pattern in your support queue is probably familiar. A user cannot start a workflow. An instance is impossible to find in a list of numeric IDs. A Designer search returns everything except the thing you were looking for. None of these are faults in the platform, and none of them need a developer. They need somebody who knows where to look.

The five below are the ones our K2 team gets asked about most often, in roughly that order. They are worth knowing whether you are a citizen developer taking your first steps in K2 or the person your colleagues come to when something looks broken. Each one takes under a minute to do.

1. Let every user start a workflow, not just the person who deployed it

This is the single most common ticket that we receive. A user tries to start a workflow, gets blocked, and the immediate assumption is that something is broken.

Nothing is broken. When a workflow is deployed, only the person who deployed it is automatically given rights to it. Everyone else has to be granted rights manually, and the right they usually need is Start.

1. Open K2 Management.
2. Go to Workflow Server, then Workflows, and browse to the category holding your workflow.
3. Select the workflow, then open the Rights tab.
4. Click Add.
5. In the Search field, switch to Groups, keep the Label as K2, and search for Everyone, or for the specific group or user you want to grant access to.
6. Tick the group in the results, then click Next.
7. Tick the rights you want to grant. Start is the usual one, plus View if you also want people to see instance status. Leave Admin unticked unless it is genuinely needed.
8. Click Finish.

The workflow now shows Everyone with Start set to true in the Rights list, and users can start it themselves without a ticket.

2. Try Retry before you go digging into a workflow error

An instance sitting in Error status looks alarming, and the instinct is to open the workflow and start hunting for the fault. Often there is no fault. Many K2 errors are transient, caused by something like a temporary connection issue rather than a problem with the workflow logic.

1. Open K2 Management, browse to the workflow and select it.
2. Open the Errors tab. Any instance currently in error is listed here, along with the step it failed on and a short description.
3. Select the error row and click Show Details to read the full message. Do this even if you intend to retry straight away, because it tells you what actually went wrong and whether Retry is likely to help.
4. Click Retry.

If the cause was temporary, the instance clears from the Errors list and carries on running, with no changes to the workflow at all.

If the same error returns after a retry, that is your signal it is a real issue, for example a service that is misconfigured or consistently unreachable. That is the point to investigate properly, or to raise it with your K2 partner, ideally with the Show Details text to hand.

3. Give every workflow instance a readable Folio

If you have ever tried to find one specific instance in K2 Management using nothing but a numeric ID, you already know why this matters. Folio is a short, free text label you can set on an instance, and it can combine static text with live data from the workflow itself.

1. In the workflow designer, drag a Set Folio step from the Basic toolbox onto the canvas, immediately after the Start step.
2. Select the Set Folio step. In the configuration panel, type your label text into the Folio field, for example “Annual leave request:”.
3. Open the Context Browser on the right, pick a variable holding the dynamic part of the label, such as a reference number or the requester’s name, and drag it into the Folio field after your text.
4. Deploy the workflow.

From then on, the Instances tab in K2 Management shows that label in the Folio column instead of an ID. Combined with Quick Search, it makes finding, discussing and troubleshooting a specific instance far faster, both for your team and for whoever is helping you support it.

Worth adding to every new workflow as a matter of habit. Adding it later only labels the instances that start after the change, so the earlier it goes in, the more of your history is readable.

4. Turn on System Objects search to find K2’s native SmartObjects

By default, Designer search and Browse only show you what has been built for your own solutions. K2 also ships with a large set of native, built in SmartObjects, things like Process Instance, Process Data and Activity Instance, which sit under a System category that stays hidden until you switch it on.

1. In K2 Designer, open Browse (All Items).
2. At the bottom left, click the Show filter.
3. Tick System Objects, alongside SmartObjects, Views, Forms, Style Profiles and Workflows.
4. A System category now appears, with subfolders such as Workflow, Management, Identity and Reports, each holding native K2 SmartObjects you can use.

One thing to know before you go looking. These system SmartObjects cannot be edited directly. Open one and you will see Save As, Design a new view and Generate a view, but no Edit option, because K2 itself owns and maintains them. If you need to adapt one, save a copy first rather than trying to change the original.

They are most useful for building custom reports on workflow and process data without having to recreate that structure yourself.

5. Check your K2 version without leaving Designer

Knowing your exact version matters more than it sounds. It decides which behaviour you should expect when you compare one environment against another, and it is the first thing your K2 partner will ask you. You do not need to open K2 Management or find an administrator.

1. Open K2 Designer.
2. Click the Nintex Designer logo at the top of the page.
3. The About the Nintex Designer window opens, showing the version under Last Update, for example Nintex Automation K2 5.8.x.

Ten seconds, no admin access required.

A few more habits worth adopting

• Naming conventions that double as documentation. Prefixing workflows and SmartObjects with the solution they belong to, for example HR.WKF.AnnualLeave, means anyone searching Designer can tell which solution an item belongs to without opening it.
• Categories from day one. They work like folders in Designer. Skipping them on anything beyond a small pilot makes larger solutions much harder to navigate later.
• Rules Designer over stacked decisions. For anything beyond simple routing, the Rules Designer keeps business logic centralised and the visual canvas readable.
• Context Browser before typing. Check what fields, references and functions already exist before writing anything manually into a field.
• Copy and paste steps rather than rebuilding them. Faster, and it avoids small configuration differences creeping in between near identical steps.
• Test from K2 Management, not just the form. Starting a test instance from Management with representative data surfaces permission and instance level issues earlier, in the same place your future support tickets will come from.

Where this knowledge usually lives

None of this is complicated once you have seen it done. It is the kind of knowledge that normally travels informally, from one K2 developer to the next, and leaves the organisation when they do. If your team keeps hitting the same small snag, write it down and share it rather than raising the same ticket every time.

If the same tickets keep arriving anyway, the gap is usually in enablement rather than in the platform. As a Nintex Premier Partner, AMO supports K2 estates from upgrades and fix packs through to training your own team, so fewer of these questions need to leave the building.

Get in touch with our team