I’m currently working on an app that I would like to use across the entire company regardless of business structure. This app would load data dynamically, similar to table-based WI, based on which station was using the app within any specific business. This would allow for enterprise use of apps such as 5S, and be able to collect data all within the 1 [log] table, and be able to filter/aggregate data into interactive tables.
I’m hoping to achieve this through a OOTB Stations table, similar to the Users table, where ID fields cannot be changed through apps, but allows us to add custom attributes to the table.
Or, another way I think I could achieve this, would be to have Nested Station Groups. I.e. Group within a group, but would still need to be able to access the Station name/group/list from within an app.
This would also contribute to complete data traceability, and limit the number of tables/apps required for enterprise use.
Each record would have the following attributes: [company name]->[business segment]->[business name]->[site name]->[station name]->[app name]->[user name]->[save completed app data].
Is there any chance of this being considered for product development? Anyone else find a quick and easy solution for this?
Thank you for the product suggestion around the station’s table - this is a great consideration.
Regarding your request around nested station groups - do you anticipate needing several layers of nesting and what would each nest represent on your shop floor?
I wasn’t looking at station groups specifically for the shop floor. The way Groups currently work is by Business site, i.e. physical location, So I have a station group [Station Group 1] then any apps I apply to this group will be seen by all of the sub groups.
Extend this idea for enterprise clients. What if I had a company with 320 business sites, and I wanted to roll out the 5S app to all of the station groups across my enterprise, i.e. all station groups at all sites, then the station groups functionality/capability breaks down. You can only have 1 layer of nested group capability.
Our network of US Field Inventory sites could benefit from an expanded group membership as well, but it wouldn’t necessarily be as hierarchical, and it might need to be such that a station can belong to multiple groups ad hoc.
For example, all of the sites/stations would need access to Surgical Kit Check In, but only Chicago would need the Torque Calibration apps (because that’s where the calibration happens), and only some of the sites/stations would need the Torque Deployment apps (i.e. the ones that carry calibrated torque devices and need to recieve/return them when calibration is due).
Hey jm, any chance you could upvote this suggestion? I think that’s how product development works here, if I can get enough votes for this, maybe they put it in the pipeline?
I’m totally with you, that a single layer grouping system is not as powerful as it could get.
But I’m also not a big fan of this folder structure at all (no matter how many layers).
What do you think about a tag system?
That way you could easily define exceptions by simply not giving a tag of a higher level and you could add a station to more than one tag on the same layer as well (e.g. cross-departmental projects).
You could define two layers of tags. The first is a main tag (one station can only have one of them) and serves as a sorting criteria (as the current folders).
This is similar to the sorting system in this forum.
Thats what I was getting at - tags vs. hierarchy, tags would be better. It would help if you could multi-select stations or station groups to apply/remove the tags, rather than having to execute for each station individually.
Hi @BillyJo, from a Tulip perspective, I would like to challenge you to review and reconsider your original premise of developing “an app that I would like to use across the entire company regardless of business structure”. Such a design is what we consider to be a “monolith” vs. our recommended best practice of building something composable. Much of the development challenges you may be running into are commonly associated with building something “monolithic”.
By and large, we find our customers have the most success implementing (and sustaining) solutions that follow a Composable architecture and our Solution Credo.