Edit Workflow Parameters or Variable Values

InsightConnect
1

What’s the easiest way to modify the value of workflow parameter or another variable in the workflow?

For example, I have workflow parameter “BlockUser” set to “false” in the workflow. After some steps I’ve determined I’d like to block this user and I want to set that particular variable to “true”. I’d also like to be able to modify Step Variables as well.

Thanks.

2 Likes
2

Hey Paul, thanks for posting. That’s a great question.

I would say that the best way to think about this is going in sequence building up new variables, rather than modifying older ones or parameters.

For example, if you have BlockUser as False, and at some point determine you should block the user, then you’d do the operations within that decision branch where you’ve made that determination.

If you ever need to refer back to that decision thereafter, you can reference the decision step “path” variable to see what path was taken (aka what decision was made).

I totally get the convenience of wanting to just make a change to something, but in general InsightConnect works better if you think of it as building up steps and decision paths and taking action based on the latest values.

Hope that makes sense. Let me know if you have any more questions.

1 Like
3

I think I’m asking for this due to two different use cases.

  1. We’re trying to build some reusable components for building multiple similar workflows. For these workflows we can use a template as a starting point. Workflow parameters seems like an easy place to store variables for things that would apply to multiple workflows and we can just change them as we import.
  2. When we hit a decision step the business logic might be complex. To determine whether to block an user there may be several other decisions above with many different steps. We’d need to remember the various step variables from above in order to write the logic in the block user decision step. And if I’m joining multiple decision steps above already it seems like I’m trying to get down to one single variable to tell me if I need to block or not.

Hopefully that make sense. Thanks.

4

That makes a lot of sense, and is a good argument for having a general class of more important variables that are perhaps easier to access than the rest of the step variables, and giving them some clear meaning in the workflow. I’ll pass this feedback to our product team, I understand it for that level of complexity for sure.

5

Something else that might help here. You don’t have to carry a boolean through the WF to check for success. (That’s something I’d do while programming, but InsightConnect works a little differently).

You can always do something like

if is_defined({{[step].["success"]]}}) AND {{[step].["success"]}}

To check if a step returned a boolean, and if it’s True.

For complex logic you can string those together to see if several steps executed correctly and you received the results you wanted.

EDIT: Also a step will ALWAYS return $success if it executed. So you can use that variable to see if a step passed or failed, then move on to checking the results.

6

I’m in the same boat as Paul, currently I’m using the storage plugin and i know that is going away but it is doing what I want. I create a storage variable using the JobID then I reference that multiple times in my workflow. I could accomplish this with Join and Loop outputs, it was just natural to think of global variables I guess.

7

My three bosses are forcing me to say “don’t use storage.”

Jokes aside, storage is fine for this, but I wouldn’t recommend it for anything that’s going to live beyond the current WF. If the orcha is restarted for some reason (say an upgrade), or the Storage plugin is stopped / started, there’s a high likelihood it wipes out it’s own cache, and you’ll lose data.

It’s also slower to use than Global Artifacts or Parameters.

But all in all, it still has some use left in some very specific senerioes. Hopefully we will have that functionality available in other features soon though.

8

Yeah, I was waiting for the ability to delete from Global Artifacts.
Or I’m thinking about reworking the Workflow to use Outputs (this will in turn speed up the Workflow as well)

2 Likes
9

Makes sense, and just to follow on we have started working on a delete operation for Global Artifacts so we should hopefully be able to help more with this use case relatively soon.