Hi @brandiwoodson 

1. The Output from most "Connections" type resources is a Read-Only Object.
This includes the "SP Online - Query a List" action.
You can't update any values in this Object or delete this Object (programmatically in the workflow). 

2. Each time you make a new SPO Query a List, a new Output variable is created.

When the Query List action is duplicated, a new Output object is named automatically. "SPObject 1", SPObject 2"

You can create a new Output variable but you cannot select (re-use) the previous used Output variable (Object type).

3. Trying to Clear the Collection of the Object will result in the following error.

4. Probably, the main reason why you wanted to re-use the Object variable is to display the values in a Log or Email or use the values in some calculations. 

Making copies of the Log/Email will not work. You will need to re-assign the values because you need to refer to a new Output Object.

Thanks for the feedback. Exactly what I was afraid of....I thought this action was a workaround for clearing an entire item (list item) that was added to a collection.

Understand what needs to be done and we aren't happy about it.  We absolutely need a way to constantly have the latest version of a list item without updating the default values for each new task form. 365 doesn't require this since I suppose it sits on top of the associated list or library in SPO. 

It's just way too many extra actions in NWC that we have to include and too much info we have to update for new task forms for each level of a review and approval process when trying to show the latest version of an item for the next approver. Several of our processes include someone reviewing and possibly editing som information and then actioning the task. 365 ....we could just copy tasks all day long and just point it to the next approver.....

When you have 200 possible fields that could potentially be updated on one task coming from a list item it makes it super frustrating to have to relink default values in the next task form that is sent out. 

Not so problematic for ones that don't require editing potentially and only a status field is being updated but for sure if edits are necessary.

This is an issue that you can’t reuse the same collections. It would be so handy in our case. We have a workflow that updates items permissions on various lists.

We have 6 lists and using a “branch by value”, each path does a “query a list” against the specific list and then outputs the result into a collection object called “ListItems xxx”

Then after the query and outside the branch by value, we would like to run ONE loop that updates the permissions of each item as appropriate. 

But we can’t because NWC is forcing us to create a new Collection Object with each query.

This totally sucks.

So we have to repeat the for each loop after every query to use that specific collection object returned  (eg, ListItems, ListItems 1, ListItems 2, … ) from the “query a list” actions.

Such a hassle and completely ridiculous we have to do it that way. I understand NWC has to do it that way because otherwise it doesn’t know the fields in the collection object, but surely there must be some way around this to make it easier.

Not sure if this is helpful or feasible depending on your workflow, but in some cases you can “reuse” a collection by re-running the same exact action that produced the collection in the first place.  Usually this would involve some kind of branch by stage logic, where one stage will get the updated information, then dynamically set the next stage to the next step in the process.  

This is an example of that:

In this case, the each of the log to instance actions are logging the value from the same collection object, which is “refreshed” each time the Query a list action runs. 

The annoying thing is that this proves that collections could be reused, it’s just prevented for… some reason?