#Plain text workflow iso#

Then we repeat that query but for all items in that timeframe, configure all parts of the second query the same, except for:ġ. Now we log the total number of items returned with a token into ‘Result Count’:

#Plain text workflow iso#

Then we are also running a filter on our adjusted UTC time variable (remember, this is the ISO time output): You can see in this first query, we’re getting only items that contain the token. Here is what the setup for the query looks like: Please note that we need to use “ Output as an ISO 8601 date string” to define the UTC variable to work in queries.īecause we cannot use “Does not contain” as a variable in these list queries, we need to run it twice. Now that we have our log’s timeframe correct, we can run our queries against the Workflow History list. So, for us, we’re logging the start time as a variable (to use in email), then adjusting for UTC and setting a second variable (to use in queries): For this example, we are logging hourly, so we need to get the current time minus one hour.ĭepending on where you are in the world, you’ll need to make more adjustments based on UTC, which is the default record for each timestamp. Next, we need to get a few different times as variables, like the current time and the time when our log started. Now let’s start the workflow build… here we log that the workflow started first, then we’re sending an email to tell us that it started (more on that later). Create a Custom List and leave everything default. So, now we need to create a monitoring list, which can be on the site running workflows or it its own separate site. Now for every time something is entered into Workflow History that we have control over it will have this, RP?WoRkf1oW, token.

So, for instance if I log that a workflow started, we need to add this unique token to the end of the text, like so: Start by taking all workflows currently running and whenever a description is logged, you’ll need to append a token to the end of it. This means we can’t just run workflows every time something is logged to this list. Because these history items are ‘special’ in SharePoint, we cannot start a workflow on them when they are created. Remember that awesome door/window phrase I made up? It’s true here too. This logs messages when workflows enter a suspended state with an error message (most of the time). I like to see the Parent Instance, Association ID, Date Occurred, and Description: Then we need to create a view that allows us to better track the status of incoming history items. You can do this by navigating to your site where the workflows are running, then appending this URL: Probably not, because I just made it up, but it’s true.įirst, we need to locate the hidden Workflow History List. Remember the old phrase, “When SharePoint closes a door, it opens an extremely small window, with steel bars and barbed wire and rat traps waiting on the floor on the other side?” The nice lookup column that Nintex uses On-Premises (where the workflow name is the column title, then creates that lookup to the internal status field) is also not available in SharePoint Online for this reason. The internal status field, however, is the only way we really know for sure if a workflow has been suspended. Since this can’t be done in due to Office 365 restrictions on database access, we cannot set workflows or alerts based on this field. The internal status field in workflows is only available by querying the database directly. I’ve chosen to write and show it in Nintex because it’s both easier to create and easier to read.

One small note before we dive in, this will work for both Nintex Online and SharePoint Designer Workflows. Let’s walk through a quick and dirty way to add workflow monitoring to our cloud-based workflow.

This leave us without a way to know when and if a workflow has been suspended. A major concern in the transition from workflows with SharePoint On-Premises to SharePoint Online is that the monitoring features that had previously been available are now limited.