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.
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.
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.
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.
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.
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.
Once you have connected using the MongoDB input, the user ID field should be parsed with a JSON Parse tool.
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.
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.
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.