Expand my Community achievements bar.

Latest Community Ideas Review is Out: Discover What’s New and What to Expect!

What is the difference between GROUPS / COMPANIES / TEAMS?

Avatar

Level 2
Hi Everyone - So we have teams within my department that work closely together that have private information that cannot be disclosed to other teams. I would like to build a request system specifically for those specific teams who need to communicate the private information. What is the best way to organize this structure? Thanks, Jill Jillian McGovern Project Manager NYU Langone Health New York, New York E: jillian.mcgovern@nyumc.org P: 646.754.7358
6 Replies

Avatar

Level 10
Hi Jillian, So Groups are whatever you define (typically most of us use Divisions as Groups). Company is, well company �� . Teams are whomever you decide to define as a Team. You can be on multiple Teams as well. You can use all three of them to control Access, notifications, etc. For your scenario, what we do is build a request queue project (that contains your menu name, custom form and who can submit to the queue, etc.). Then we create a "landing project" and we route the requests here (via the routing in the queue project). The landing project controls the access of who can see what. The one exception is the Requestor will be able to see their own request as this will be inherited from their submission and they need that access to edit the Form. However, you can always add Admin only sections to the form that they won't be able to see. That's basically it. That landing project allows you to control that access to whatever degree you like. Let me know if you need more information.

Avatar

Level 5
Hi Vic, What is a 'landing project' exactly and how does this differ from the request queue project? Ty Miranda Rais GVC

Avatar

Level 5
I'm new and learning thro trial and error....so, with that said....here goes.... Groups and sub-groups = can build a request queue for them - however, the overall group has access to both custom forms. We split reviewers into sub-groups. We split our workers into teams. Teams means we can report on the home teams tasks etc....whereas this is not important for reviewers. When i wanted a private group, i needed to create a new group and a request queue for that....so, i'm really intrerested in the landing project Vic mentioned and I have asked for more info about. Eventually we will use companies too and you can limit access via your access levels in the advanced part to see info just the company people belong too, as well as groups... Hope that helps... Miranda Rais GVC

Avatar

Level 10
Hi Miranda, It's just a project. It's an unofficial term �� . I chose to call it a Landing Project because that's where your Requests will land (after you route them there from your Request or Queue Project). In the settings of the "landing" project you can control who accesses the requests. You do this via the Sharing to overtly prevent and add access. And also under Edit Project > Access to control access to anyone that's assigned or submits requests. And you can control that access for Individuals, Teams, Groups, or Companies. Let me know if you need more information.

Avatar

Level 5
Hi Vic, Ok, understood and thanks a lot :) Is this used purely due to access rights? What is the usercase / limitations on this approach? Thanks! Miranda Rais GVC

Avatar

Level 10
Hi Miranda, Honestly this is the approach that was taught to us by our WF Implementation Consultant 4 years ago. At the time we didn't really understand why. But he was the expert and we knew nothing so we did it. Over time I've come to suspect that it was for the access and to keep the access controls separate. So it's helped us control the access rights to the requests themselves and keep them separate from the access to the menu itself. For example, I may want to give someone rights to see the requests (i.e. a Supervisor), but not have it show up on their menu. It also prevents me from inadvertently giving someone access they shouldn't have (down the road when I've forgotten something should be restricted). You can probably accomplish the same thing with one queue project, but I've done it that way too, and I prefer having the flexibility in the access. And I don't know of a downside to this approach, other than making sure you remember you've done it this way and understanding your landing project will control the access. And either approach you use, you must have the setting under Edit Project > Access set to Contribute (or they won't be able to edit or see the custom form in the request). See attached. Another tip would be to name the landing project something similar to the menu project so it's easy for you to spot there's a connection (and to find it without going into the routing rules). For example, my menu project might be "Helpdesk". My Landing Project would be "Helpdesk Request Project". Let me know if you have any questions or anything.