Using Cloud:UserId to capture the run time user variable on Server for a more dynamic workflow

[AmalinaH]

Using Cloud:UserId to capture the run time user variable on Server for a more dynamic workflow

This article builds off the highly useful contributions of our wonderful Community members who have posted solutions on a series of discussions around this topic: @mbarone, @patrick_digan, @NathanOch, as well as Ben Moss from The Information Lab, who wrote this excellent article on their website about it.

 

Prerequisites

• Alteryx Designer
  • All
• Alteryx Server
  • All

 

The CloudId Text Box interface tool

This article walks through the use cases (the “why”), the basics (the “what”) and the set up (the “how”) of the CloudId textbox interface tool which allows you to capture the user variable of the user running a Server workflow or app at run time.

The use cases

A question that Server Admins or workflow developers may ask is how to capture the user running a workflow or app at runtime and dynamically manipulate the output of the workflow based on that user.

There are various use cases where this might be useful. For example, it can enable you to:

• Filter values on a drop down based on the user running the app
• Save to a different folder depending on the user running the app
• Provide only data that’s relevant to that particular user, e.g. specific to user’s geography, business unit or team

 

As a Server admin or workflow developer, you may prefer to capture the user who is logged in automatically rather than having the end user input their name or ID manually to avoid errors or cases where a user keys in anything.

The solution

Before continuing, it’s good to emphasise here that there may be other solutions that work depending on what you want to achieve and how you set up the configuration. One such way is to use the formula tool with the expression getenvironmentvariable(“username”).

While this works in some cases – and could fit your particular purpose – it’s not the most robust method as workflows may be set to run using the “Run As” setting configured to another credential. If that’s the case, you will not be able to identify the actual user and this may not allow you to achieve what you’re looking to.

Luckily there is another solution you can use which allows you to identify the exact user. Cue the Text Box tool , under the Interface tool palette:

image.png

 

The set up

The Text Box tool may be more commonly used to build an app where the user would be required to key in some text into the Text Box, but the trick here to name it __cloud:UserId. This is achieved by going into the Annotation tab of the configuration panel, where you can set the __cloud:UserId.

image.png

Be mindful of the two underscores and capitalization of the “U” and “I” in __cloud:UserId.

When you set it up this way, the user is not required to manually key an input into the Text Box during run time. Instead, the workflow automatically picks this variable up when the user runs the workflow. Combining this with an Action tool, you would be able to capture and store the value of this variable in your dataset. The variable captured is the Mongo-generated user ID.

An example of how you would achieve this is shown below.

image.png

Once this variable is captured, you would then need to query the user table stored on MongoDB to map the user ID to the username, Windows SID or email of the user. This can be done by bringing in a MongoDB input tool that connects directly to the MongoDB of your Server.

The configuration of your MongoDB input tool requires you to specify the Server, User Name and Password (optional), Database and Collection. These details should match your Server System Settings, if you navigate to Options > Advanced Options > System Settings > Persistence.

image.png

Under the MongoDB input configuration, the database should be set to AlteryxGallery and the Collection should be users. For the latest schema, you should refer to the Help Documentation. The end configuration should be similar to below.

image.png

Once you have connected using the MongoDB input, the user ID field should be parsed with a JSON Parse tool.

image.png

Now you simply need a join tool to match the ID captured using the __User:CloudId Text Box with the user ID in the MongoDB user table.

What next?

Once your workflow captures the user, there are a ton of things you can do next to manipulate the output of the workflow. It really depends on what you would like to achieve and how you wish to make use of the user variable.

For example, you might:

• Look up that user’s team (if you have a separate look up table), and use an action tool to update the filter tool to that user’s country, business unit or team
• Look up the user’s team members (if you have a separate look up table), and with a Chained App, set the values of a dropdown list to be filtered according to the user’s team members
• Populate a field based on the user’s name​

​​​​​​In most of the uses above, you would most likely need a separate user look up table to enrich the user’s details. These are just a few possibilities.
 

Pre-built Example

Attached is a simple pre-built workflow you can use to help get you started.

Please comment below if you have any questions or other insights. If you do have a use for this solution, I’d also love to hear your use case to help broaden our view on the various applications of this simple solution and share ideas to others.

 

[elsastark]

We like this feature - but we want to lock it down inside of an encrypted macro. Currently, it has to be in the parent workflow, but we want to put it within a locked macro for our use case, it is a security concern. 

For example, we are wanting to improve the Publish to Tableau Server tool - we do not allow our users to embed passwords in their workflows which is required by the tool. Instead, we would like to use the Cloud:UserID feature to check if someone has access to publish to Tableau, then publish as a shared account. But, if that check is happening in the parent workflow where someone is using the tool, then someone could hardcode a user therefore it isn't secure. 

We have brought this up with the Product team through our Customer Success Manager. 

[bertal34]

@elsastark 

Hi - are you able to put the MongoDB portion of the app into a separate macro?  I know that doesn't seem ideal to split it up.

[elsastark]

@bertal34 - the issue is with the capturing the Cloud User ID - we can't put that inside a macro. 

[bertal34]

Oh gotcha, I mistook your Tableau pw for that in the MongoDB tool.

[bertal34]

@AmalinaH 

Outstanding job adding this to the Knowledge base and explaining so well!!

It may be worth noting that if a user plans to copy & paste the tools into a new workflow, the Textbox interface tool name will change upon pasting.  Make sure you go back and rename the tool "__cloud:UserId"