joakim.johansson

Best practice building workflows

Discussion created by joakim.johansson Employee on Jun 28, 2019
Latest reply on Jul 1, 2019 by roland.meier3

If you have lots of parameters referencing each other where some is visible on the checkout and some are not, building new workflows can easily become a cumbersome. Over time I (and other Snow consultants) worked out a way of making life easier down the road. The solution is pretty simple but adds a layer of simplicity to your workflows.

 

How? Always start by adding a “fake” activity called “gatherPararemeters”. It’s only mission in life is to be a placeholder that can be referenced by activities placed later in the workflow.

 

The big benefit of this design is:

  1.  If you have multiple activities using the same value you only need to change them once in the gatherParameter step instead of changing them in all different activities. 
  2. You have ONE place where you configure and change parameters, making it way easier to return to a workflow in the future and actually finding and understanding parameters.

 

I’ve added my gatherParameters activity as an attachment here but here’s a guide on how to do it manually as well.

  1. Create a new PowerShell and call it whatever you want (for example gatherParameters.ps1. The only code you write in it is “param()”
  2. Next, go to Activity admin – Add activity and upload your gatherParameters.ps1. Once you’ve done that you will have a new activity that says “No parameters in activity”
  3. Press the “Add parameter” button

  4. This will show a pop-up where you can create what we call an input parameter. The parameters you add here will not be sent to the actual PowerShell script, they only exist in the user interface. I usually give them generic names at this stage, the reason being that I want to re-use this activity as a generic activity in all my workflows. So, this is a one-time job that we will benefit from in all work going forward. I recommend adding a bunch of parameters with different types.
  5. When you are done (or import the attached gatherParamers activity) you end up with something like this.
  6. You don’t have to configure anything more here. Just add new parameters when you need them.
  7. Now, let’s build a simple workflow that creates an AD user, enables a mailbox, and adds the user to some standard AD groups. It will look something like this:
  8. At this stage it’s time to start configure the gatherParameter activity, giving the parameters meaningful names and set visibility.
  9. We can also setup our parameters to call PowerShell webservices and everything else we normally do. In this example I’ve created a PowerShell webservice returning a generated userId.
  10. As you may have noticed all config so far has been done in our gatherParamers, meaning we have all checkout parameters nicely collected in one place. And in the future when we want to change something we only need to change in one place. Next, start referencing the parameters from your other activities pointing up like this.
  11. Same thing in our enable mailbox activity and also later in the add user to standard groups activity.

 

So, all set. This is how it looks in a checkout when the workflow have been added to a service called “Employee account”. We show only the input parameters from out gatherParameters activity, knowing that our “real” activities will get the information by reference.

 

This is a simple small example of using this design when building workflows. The benefits will become even more clear once you have more complex workflows with maybe 10 or 20 activities. 

 

Download my gatherParameter activity here ->> gatherparameters.ps1.AutomationBook • Droplr 

Outcomes