In this short post I will help you to build your Nintex for Office 365 workflow that will allow you to copy attachments that were added to a task to a related list item attachments. The list item is of course the one around which the whole workflow is running.
I was seeing this kind of error in Nintex for Office 365 workflows for some time, but actually never had enough determination to check what is the root cause. However when customer started asking, I started digging.
In my daily work over business processes in Office 365, specifically in SharePoint Online, one thing annoys me the most – namely the lack of mechanisms to inform me that the workflow has hung up – that it is in a “Suspended” state.
The solution for that issue is not provided by Microsoft or Nintex – the company with which products I have been working for a quite long time. There are only workarounds, but they are inadequate, and I wanted to be able to react proactively and not reactively to any flow suspension event.
Requirement where a designer has create a workflow assigning multiple parallel tasks to multiple parallel groups of approvers is complex.
Basically, Nintex offers us two approaches: either assign task to a group and wait for the first response or to wait for all responses. But what when we need to have multiple groups assigned a task in parallel?
Recently my customer asked me to create a dashboard, to monitor completion of tasks in a workflow. The idea was to highlight completed, on track and overdue tasks with different colors. First I thought about using SharePoint list with Modern Experience, and column formatting. But then I was asked, not only to highlight rows for tasks, but also their grouping header – as there were many tasks created per each group of tasks and the customer wanted to see status of a whole group ad-hoc, without a need to drill down.
I recently was asked a question: how can I use the signature from the Nintex Mobile inside a document being generated by the Generate Document action? Unfortunately this is not yet feasible only using Nintex products. This is because Nintex Workflow for Office 365 is not handling correctly the binary data (it loses null bits) so what I proposed was to use Microsoft Flow.
Still being under impression from working with Azure Functions, I decided to try finally build a solution for Nintex Workflows for Office 365, where I have a single repository of workflows’ definitions, and from here I am able to publish them across the site, to different libraries or lists. Previously I was only able to do it using PowerShell or tools like Postman or Fiddler. However I wanted to have a single workflow that does all of the magic for me.
The article is a continuation of the post describing creation of a simple newsletter using SharePoint Designer 2013, written here. This time I would like to show, how the similar solution can be made using Nintex Workflow for Office 365.
In Nintex Workflow for SharePoint (every version), when you use the “Flexi task” action, that creates and assigns tasks to specific users, if you (as a viewer) are not the assignee, workflow tells you that “You are not authorized to respond to this task.” – then to make yourself authorized you have to click the “delegate” link, then to reassign that task to yourself.
Workflow constants are a feature available only in Nintex Workflow for SharePoint on premises, allowing you to store globally used workflow variables in a single place. These variables can be then used across all web applications and site collections in your SharePoint Farm, or just in a single site – depending on the scope where they were created.
There are numerous use cases where Workflow Constants can be used: keep user credentials used for authentication in actions, keep thresholds for approvals, or keep specific dates, which are important for your company operational processes and many more, generally related to the “dictionary” purposes.