Forum Discussion

DavidLichty's avatar
DavidLichty
Qrew Trainee
6 years ago

Created a Copy of an Existing App and Want to Use Existing Fields to Link to a New Related Table

I have an app that I've been using for many years to contain common and frequenly used information about team members when assigning work.

As team members do their work, they assign each record to themselves via a drop-down list that is a relationship to the team member table in this app.  (They select Related-Team-Member.)

Our team just had a split, and some will stay with the main team, and some will go to a new independent team.

I made a copy of the app and have the team members split up so that they are listed in one of the two separate apps.

The apps that they actually do the work from (the apps that link back to the main app) have historical data.  To maintain continuity of reporting I would like to have the work app link to the new assignment app.  If possible using the same "related" field.

Ideally I would like to run reports in the do-the-work app so that the work done by team members (Bob, Mary, and Sumit, for example) would seamlessly show work they did in the past and work they do in the future.

Is there a way to create a relationship to the new assign-the-work app in the existing do-the-work app and have it use the same Related-Team-Member field in the do-the-work app to access the related record in the assign-work app?

Thank you in advance for your assistance.

- David

6 Replies

  • MCFNeil's avatar
    MCFNeil
    Qrew Captain
    If you really want the same reporting and historical data.  I'd strongly recommend you keep it all in the same app.
    BUT you can modify the roles and permissions so the two teams can work in the same application.  You may have to make a small modification to the setup.

    If they truly are the same process, same reports, and just different teams.  Use the same app, and have roles save the day.
    • DavidLichty's avatar
      DavidLichty
      Qrew Trainee
      Thank you Matthew.

      The business requirement is that they be separated.   The people will now be on completely different teams with different management.   

      If I cannot find an elegant solution now, I can wait until the end of a fiscal quarter so that the reporting makes as much sense as possible.

      If anyone has an idea of an elegant solution to this, I would be eager to hear it.

      Thank you for your consideration!

      - David in Tucson
    • QuickBaseCoachD's avatar
      QuickBaseCoachD
      Qrew Captain
      I'm with Matthew here.  You can create Roles and users in restricted Roles will not even know that the other Team Exists.  Or give up on ever having Consolidated reporting.  And also, if you split the app,  every time someone has a bright idea to improve the app, you have double work to maintain two apps.
    • DavidLichty's avatar
      DavidLichty
      Qrew Trainee
      Hi Mark, Good to hear from you.

      I agree, that would be nice.

      This is a dictated business request.  Imgine that these former teammates are going to be working for different companies and won't have access to the same data any longer.

      The specific data for the work each team does will stay with them.

      The link method I'm trying to preserve is to the table that lists all the team members, their managers, their desk-location, phone number etc.   This person specific data is being split.

      Since the date of the work they did is associated with them I'd like to maintain that association while splitting out the actual people across two completely different teams.

      The key between the relationship is their Quick Base User ID, so that will remain the same.

      When I make a new relationship to the new (split off) team's worker app/table, I end up with Related-team-member-1  and Related-team-member-2.
      (1 links to the original app/table, 2 links to the new, split-off app/table).

      As I'm spelling it out in more detail it is clear that it just can't work.   I'll go for the wait until the end of a reporting period approach.

      Thanks to you and Matthew for helping me process this!


      Thanks,

      David
  • Can you tell us al little more about your structure and which related field you want to update or keep?

    I do not get this;

    "Is there a way to create a relationship to the new assign-the-work app in the existing do-the-work app and have it use the same Related-Team-Member field in the do-the-work app to access the related record in the assign-work app
    • DavidLichty's avatar
      DavidLichty
      Qrew Trainee
      Hi Esther,

      There is a pair of apps that have been working for years.

      • One part of the pair is the work being done.
      • The other part of the pair is the details about who does the work.
      • There is a relationship between the two so that people doing the work can select their name from a drop-down list to indicate that they did the work -- thus letting managers run reports on productivity.

      Due to a business change the team members will be splitting to wind up in two completely different businesses.

      I want to maintain the functionality for all concerned, however must split the people into two different who-does-the work tables.

      Since productivity reports are linked to who did what, once I make this new relationship, I'll essentially have the same person showing up as two people -- one from the old team, one from the new team.

      I was looking for a way to preserve continuity of reporting while making the split and through the conversation above with Matthew and Mark, realized that this logically canot happen.   Even if I could change the pointers as I was hoping to, it would break the historical records -- since it really is two different who-does-the-work tables, there is not a way to use one field to point to both of them.

      So, I've chosen to keep the existing set-up until the end of the next fiscal reporting period; and then make the change.   This will at least make reporting logical and the changes will not cause confusion.

      Thank you,

      David