2012-11-20 07:54 AM
IHAC who is a massive global auto manufacturer. Their storage team is truly global as are their storage operators. They've asked an excellent question that would make WFA very attractive to them:
Can a single workflow offer different user inputs (i.e. a drop-down list of storage arrays) based on the user ID or the user group they belong to? For example:
Does WFA have this capability to dynamically change selection criteria based on which user or group is executing the workflow? If so, please explain how as I'd like to set this up in the lab to demonstrate to the customer.
Solved! SEE THE SOLUTION
2012-11-20 09:30 AM
That's a great idea, but at this time I don't think that's possible. What is possible is to clone the same workflows and change the query for which controllers get displayed according to each group that you want, then create separate categories for these workflows with the "Use for Workflow Authorization" checkbox checked, and add the users to the appropriate category. It achieves the same functionality with a bit more complicated setup and maintenance of the workflows.
2012-11-20 12:15 PM
Thanks Dave. However, that scenario is exactly what the customer is trying to avoid. They don't want to have to maintain multiple copies of the same workflow to accommodate different geographical groups. This results in higher management overhead and a greater chance of inconsistency working its way into operations. For example, someone updated an important workflow with a new step, but forgot to update the same workflow for other geographies. They may not catch that mistake for months, during which environments are becoming more and more inconsistent due to the discrepancy between workflows.
I'll have to ask the development team if this is something we could request for a future release. I could see this being utilized by multiple customers.
2012-11-20 12:32 PM
Due to the nature of WFA being an automation framework, this is not possible today... natively. Now there are several ways that you could control these types of user inputs:
I realize that these answers are probably not what you were hoping to get but honestly these are the only available options today.
2012-11-20 01:15 PM
Easy enough to filter based on a selection like have the user select the group or custom comment tag, but that's still leaving the choice up to the user. Without being able to pull the user ID that logged into WFA into the SQL query for the user inputs, it's not very secure. If we could query an environment variable or something from the SQL attached to the user inputs to determine the user ID that logged in to WFA, then access could be controlled through DFM/OC-UM groups or via custom comments on the controller objects in DFM.
Without that, we're left with the unhappy choice of what I mentioned first, or a custom portal, and both are a lot of overhead.
2012-11-20 04:57 PM
So here's a definitive answer and I believe you'd be happy with it:
I've encountered the need in the past and created a feature request for it.
In 2.0, if you'd go and define a user input called "$_WFAUser" you'd be able to get that value (Of the user currently logged in to WFA).
It would be a read only input (ie shown on the screen in preview) with a pre-defined tooltip.
You can use it in queries to correlate the logged in user with information from additional tables (Either native ones from the DFM cache
or with proprietary info from the user-specific playground DB).
While admittedly it can use a little more polish - I believe this is very usable and will offer a viable solution to most use cases.
Hope that would help as I think it will.
2012-11-22 11:30 PM
Maybe I misunderstood the question, but is it not something that needs to be covered using something Role Based Access?
Because, if an administrator has access to the wrong system, he could still (manually) execute whatever (s)he wants.
In case of a foolproof WFA environment, the workflow needs to verify upfront if the correct access is available. Alternatively the workflow needs to be provided with good error or exception handling.
2012-11-26 05:44 AM
Reid is describing a different use case than the RBAC provided with WFA. You are correct that WFA would confirm access prior to workflow execution. RBAC is done at the category level in WFA. An operator would never be presented with a workflow they were not authorized to execute, so there's typically no need to have RBAC functionality within the workflow itself.
And now that we have this $_WFAuser functionality, we can customize workflows according to the user name that logged in as well, so the best of both worlds now.