I would love to see the addition of app assignments to specific users and/or user groups. Specifically, I would like the ability to show/hide apps in the Change App menu based on the User that is logged in…not based on the Station being used.
I did some searching and only found this post which is now marked solved however it wasn’t really solved…more of a work around. I do use this method to kick people out of apps that they shouldn’t be in however it would be better if I could prevent them from getting there in the first place.
I’m likely not the only company to create a custom app launcher app to accomplish this. I even went as far as removing all app assignments from all stations, so the teams are only able to change to my app launcher app.
Hello Darren, glad to see you are trying that approach- that is what we currently recommend for all customers that want to accomplish this. I am curious, what are some issues you are running into with this approach?
@kevin.kononenko the method I use specifically is a different step for the type of user that is logged in. When the app is started it checks a Users table custom field to determine which launcher step should be displayed. (ps. I know this could be via User Groups now)
First issue is the difficulty in keeping it organized as the amount of app links grow. It started with roughly 5 buttons on the Base Layout for everyone and a few user specific buttons spread out across the steps. Now I’m at closer to 15 apps for everyone which do fit but it’s just getting messy.
Second issue is the user types are not so clearly defined anymore. I used to have a single step for Quality type apps but then had to break that out into Quality and Quality Management as they have need to have different rights/access. It’s getting close to needing to just create a custom step for each employee instead of grouping.
The last issue I have is how the Logout/Login works. When a high-level user logs out from this launcher that higher level user step will open back up for the next person that logs in regardless of the custom field associated with that next user. To combat this, I need to put a trigger on every button to re-check if that user should have access to the app even though technically, they shouldn’t even see the button in the first place.
Interesting! I see how this could become hard to track/unscalable.
I am still leaning towards solutions with the existing feature set simply because this would be a very large change to our paradigms, and we would need to consider how it intersected with the existing Stations and Devices model, so unfortunately it is not so easy to add yet.
As for the scalability issues, are you familiar with the “Complete App then Change App by Name” transition? I have an idea that might require less logic here, but it will require you to use that transition.
@kevin.kononenko Yes, I use the Complete App and Change to App by Name action a lot with my app launcher. It is basically just a bunch of buttons that use that action to launch the respective apps. The scalability issue is more related to physical space on the step.
I can’t implement a super tall step that the user could scroll up/down.
I could make Next / Back buttons to have multiple steps of buttons, but this is a challenge due to having custom steps for each user group…no I would need customer sets of steps for each user group…possible but not great.
My next thought was to create a table with app names, app icons, list of users allowed to access it each app, and then just embed the interactive table into an app that is filtered to the logged in user. This would work but I wanted to post here first before moving forward with that.
Yeah, Id be curious if any other community members have faced this issue and how they solved it. Since launching the “user groups in if statements” feature, we have not heard very many complaints similar to this, so we do not plan on releasing a formal feature around this soon.