There are many reasons that we may need to delete a workflow from our environment but most of the time it is just not needed anymore. Perhaps it was used for a test or even a single use effort to mass update data. Whatever the reason, removing the workflow from your environment is best practice as it frees up resources and keeps your environment clean.

Finding the Workflow

In order to delete your workflow, simply locate the site and list or library that is resides on and navigate to it. In the list or library ribbon, you will see Nintex Workflow. You want to start here and click into it to see your workflows for that object.

If you are looking for a Site Workflow, you just need to navigate to the Site Contents and scroll down to the Nintex Workflow for Office 365 app and click on that.

Deleting the Workflow

Once you have navigated to the object of where your workflow resides, click on the ellipsis to the right of the workflow and select delete from the options.

You will be prompted to confirm your selection just to be sure you really want to delete it. Keep in mind that this is permanent!

That’s it! You’ve successfully deleted your workflow.

Final Thoughts

Keep in mind that deleting a workflow is permanent. Meaning that you cannot get it back once it has been deleted. I would recommend that you take an export of the workflow and any corresponding task forms in the event that you need to reinstate everything.

Another question multiple times means another blog! There seems to be no clear directions on how to accomplish this, so I decided to put it down on (digital) paper so we can all benefit!

If you have worked with SharePoint ever, and tried to do something with dates, you understand that pain that comes along with a date column… the time stamp. I am not going to go into details on why SharePoint insists that everything has a time, but simply focus on how to remove the time piece within a workflow.

For this scenario, I took a super simple approach. I am getting the current date (Add Time to Date) and then formatting a string to only contain the date (Build String). Keep in mind that if you already have a date variable, you can use that variable and skip the first step. So, let’s go!

Step 1 – Get Today

Here we simply use the Add Time to Date action to get the current date and time (when the action is executed) and that’s it. I told you it was simple 🙂

Step 2 – Remove Time

No, I am not a wizard, I can’t remove the passage of time…but I can remove the time stamp from the variable using a Build String action! In your action, click on Advanced Lookup, the Workflow Variables (in the dropdown) and then select your variable you need. At this point, if you already had a variable in place, you can use it, just select it via the Advanced Lookup and not the Insert Reference to the right. 

The reason we do it this way is so we can specify how we return the data out of the variable. Click on the “X” to the right of the variable dropdown and you can change the date format. Here we want to select “Short Date” in order to get MM/DD/YYYY

So now we have our current date without the time stamp that SharePoint insists giving us! This is great for doing date comparisons or adding date values into a document generation action.

Last month I wrote the first part of this blog and that was focused on the Nintex Form piece of this solution. This month we will focus is on how to take those individual items on the single form and create a list item for each one. There are many scenarios that this could come in to play such as breaking out each item in a request to better understand metrics or even running processes on individual item rather than on the entire submission. Let’s jump in and take a look on how we can tackle this.

Scenario

For this scenario I will continue from the last blog and frame it as an expense report. The report will allow for each submission to have multiple items on the report, but we want to break out each item into a separate list for additional processing. For this, we will need to create a separate list to push the necessary data into. Here columns I created for my list:

• Date of transaction (Date)
• Description (Single Line Text)
• Amount (Number)
• Vendor (Single Line Text)

Keep in mind that this is the list is where the items will be pushed to in order to process them further. The next step is creating the workflow that will push each item into this list. This workflow will be on the list where your form resides.

The Workflow

The workflow itself is not overly complex as we are gathering each node in the XML structure and then creating a list item for each item in the XML (in the form). I break it down into two section, Query XML and Create Item.

Querying The XML

Let’s start with querying the XML in a parallel block to help speed up the process a bit since we are going after different nodes each time. For the Query XML action, you just need to pull from “Content” that is already on the item in your list (this is why we connected the Repeating Section Control to the RepeatingSectionXML list column). Once you have the query pointed to the right place, place your XPath query to the desired node you want to pull back. I recommend creating an item (filling out the form and submitting) in your list to look at the XML structure for your specific use case. Here is what mine looks like:

<?xml version="1.0" encoding="utf-8"?>
<RepeaterData>
	<Version />
	<Items>
		<Item>
			<_x0036_110e1da-1f9e-4f14-8766-c9ebb6610df6 type="System.DateTime">08/03/2020 00:00:00</_x0036_110e1da-1f9e-4f14-8766-c9ebb6610df6>
			<_x0032_e7e5e75-9cbc-4d7b-89fc-70983844451d type="System.String">Description Goes Here</_x0032_e7e5e75-9cbc-4d7b-89fc-70983844451d>
			<_x0038_f5c375c-86f6-4218-b493-af99e1dc5e2f type="System.String">100.00</_x0038_f5c375c-86f6-4218-b493-af99e1dc5e2f>
			<_x0030_a6cd3d3-1fdc-4e65-90bf-85c2720412da type="System.String">Vendor ABC</_x0030_a6cd3d3-1fdc-4e65-90bf-85c2720412da>
		</Item>
	</Items>
</RepeaterData>

What you will need out of this is the name of the node (My Date of Transaction nodeis : _x0036_110e1da-1f9e-4f14-8766-c9ebb6610df6). This is what you can paste into the //Items/Item/{Your_Node_Here}. Store the results in a collection variable so that you can loop through all of them. You will need to re-create this action for each node (list column) you wish to grab data from.

Creating Items

Now that we have all of the data points we need, all that is left is to create a list item. This is rather straightforward, but we need to ensure that we line up each piece of data so we do not have mismatched data in our itemized list. In order to accomplish this we will loop through a single collection and pull the corresponding data point based on the index we are on. I chose to loop through the Vendor collection and store the output in a variable called VendorName and ensuring that I capture the index in a variable (called index).

With the index, we can easily pull the corresponding data from all of the other collections that we gathered in the previous part of the workflow. This ensures that all of the data will line up when we create the list item. Again, here we are using the parallel block action to speed up the processing time a bit, so once you have one Get Item From Collection action configured, you can easily copy and paste for each collection you need to pull from. All that is need when configuring the Get Item From Collection action is the collection you wish to target, the index to pull from, and what variable you want to store the result in.

Once you have all of the data pulled from your collections, the last step is to create a list item from the data. We will first pick the list where we want to create the item (the list we created at the beginning of this blog) and pass the variables to the appropriate List Item Property. Be sure to give it a title that makes sense and leverage the references Nintex provides. Here is how it looks when all setup:

Final Thoughts

This process is meant to pull out repeating section items from a form and push them into a different list than the one the form sits on top of. The reason for this could vary, but I see this a lot when having to perform processes on the individual items rather that the submission as a whole. Workflows can be created to process each item individually. In our scenario, a supervisor could approve or reject expenses at a much deeper level than a blanket approve or reject. How else could this be leveraged? Let me know in the comments!