1 Reply Latest reply on Dec 21, 2016 9:42 AM by philmodjunk

    Assign People to Multiple Related Lists

    wraynewton

      When I was typing this, I remembered something a professor of mine often included in his syllabi: "If you thoroughly prepare your question before asking, you'll probably already have your answer." Well I've pondered over this for far too long and don't seem to be getting an answer, so I turn to the FM brain trust...

       

      TL;DR version:

      What's the most efficient way to assign people to various quotes within a project? Some people will only be assigned to one and some people will be assigned to more than one or all.

       

      Details version:

      Our solution helps track who we sent bids to on any given project. A project is one record and is stored in a table called Projects. Any given project can have one or multiple quotes. Quotes are stored in a table called Quotes and related to the Projects table via the Project UUID. People are stored in yet another table, which is not surprisingly called People. We use another table, BIDACTIVITY, to capture all of the various combinations of people and quotes that occur across many projects.

       

      Here is our current setup:

      Projects -----< Quotes -----< BIDACTIVITY >----- People

       

      Many of those people are subcontractors that will only get pricing on one quote on any given project (e.g., a glazing contractor that gets a price for sunshade, but will not care about pricing for floor mats that we may be providing on the same project). In this case, we go to the Quote layout for that one quote and add the person to the BIDACTIVITY table using a portal. (cropped screenshots are attached)


      It is often the case, however, that we have a general contractor bidding on the project and will want pricing for all of the material, meaning he/she wants all quotes we have on the project. In the current setup, this means someone has to then go to each of the records for Quotes on that project and repeat the action described in the paragraph above.

       

      For a project with 4 different quotes with each quote having a different group of subcontractors bidding, this works well. For a project with 4 different quotes going to a list of 10 general contractors, you can see how this would quickly become inefficient.

       

      I could just restructure this so that BIDACTIVITY was related to Projects and GC bidders were entered there, but then we have the problem of adding people there that do not get all of the bids.

       

      Here's the question:

      Is there a way to enter in all of the general contract bidders on one of the quotes and then copy those same bidders into all of the other quotes? I thought about several alternate approaches including, but not limited to, some type of matrix where the list of bidders would be tied to the project and then a user would just select which quote(s) each of the bidders received, but I'm not sure that's the best approach.

       

      Thoughts?

        • 1. Re: Assign People to Multiple Related Lists
          philmodjunk

          Two options come to mind:

           

          Option 1: Add a "link to all" button that performs a script to assign a selected person to all relevant items of all your quotes. This keeps your data model unchanged and keeps to a single relationship for associating people to quotes.

           

          Option 2: Add another join table and another occurrence of People to your relationships graph. Link this join table directly to Projects. Creating a join table record here and then linking a person from this new occurrence of People would be done once per project and would link them to all quotes for that project. This complicates your data model and links a person to all bid activity records so this may not work for you if you only want the same type of BidActivity for each Quote for a given project to be linked to a person thus selected.

           

          I will also note that these two options are not mutually exclusive.