Forum Discussion

AODevGuy's avatar
AODevGuy
Qrew Trainee
20 days ago

Translation Layer for an Inter-app pipeline.

Hey Qrew!

Question for your expertise.

I have a request from my userbase to create a number of pipelines to help transmit a request from one app to another.

The gist is, when a request in system A meets certain criteria, that request needs to be submitted in system B or C. The pipeline will take the request details from system A and distribute them to the appropriate system.

The roadblock I'm facing is that I have site (name, company, address, etc) and site contact (name, email, phone, etc) data that needs to be brought over from system A into B or C, but none of the record IDs match between these systems. So if I use the pipeline and pull site record ID 10 from system A, site record ID 10 will pull something completely different in B and C. 

I need either a translation layer in each system, or if there is a way to universalize without ruining existent data, I would prefer that.

As always, your wisdom is appreciated!

Pipelines

4 Replies

  • MarkShnier__You's avatar
    MarkShnier__You
    Icon for Qrew Legend rankQrew Legend
    20 days ago

    Well, this could get ugly in a hurry because it sounds like you don't have a consolidated company wide table for sites and Contacts.

    So obviously in hindsight, the right solution is to have a table which is the single source of truth that all users update for this information and then all apps will draw from that Data either in across App relationship, but a better practice would be to have Connected Sync tables in each of the apps so the users get to see what's in the site table in the Contacts table locally within their own app. It also prevents Cross application dependencies which will approve the performance of the apps if you have a lot of data or a lot of transaction volume. 

    Assuming factors like people names and site names are spelled perfectly exactly the same in both systems you can have a pipeline that goes off and searches for the site name in the other application and then uses that Record ID.   But in free form data entry in the separate systems for the site name,  it's very easy to get slightly different site names for the same physical site.

    An interim solution would be to populate some pure data entry fields with those details and have a human intervene where the pipeline wasn't able to find an exact match.  

    • AODevGuy's avatar
      AODevGuy
      Qrew Trainee
      20 days ago

      100% correct, I have been kicking myself all day. But these systems were made for folks who were fairly fierce in their defense of wanting to be independent. Moving forward, I will 100% be standardizing.

      I wish they were the same, but naming conventions and fields per site/site contact vary between app A and B/C. So extra layer of confusion there. 

      I might have to just standardize across all the apps, at least as far as naming and nomenclature go. 

      • MarkShnier__You's avatar
        MarkShnier__You
        Icon for Qrew Legend rankQrew Legend
        20 days ago

        Well, I suggest that you get someone higher up in the organization like head IT or some department decree that we are going to have centralized tables for common information like contacts and sites and customers. Things like that.  Then you tell everybody not to worry that everything will be transitioned on a calm orderly basis.  

        Then I suggest you create a table in a dedicated app, perhaps called shared tables app, and have that be the source of truth. You can start that off by copying one of the tables in one of the apps that has the best data.  

        Then you create connected Sync tables in the various apps to replicate that every hour.  

        Than any of the applications you make the relationships to these new connected sync tables  

        Then you can write a pipeline to walk through the existing sites and contacts in these various apps and try to match up those names the best it can with names taken from a new relationship to the connected sync table. Then you have humans deal with the ones that the pipeline could not match up. 

         

  • Denin's avatar
    Denin
    Qrew Captain
    20 days ago

    What is the relationship between A, B, and C? Do they have anything in common?

    Are you wanting to create new requests in B or C based on request submitted in A, or are you updating existing records in B and C based on A? Do you need these records synced or related in some way?

    If you need some kind of match or sync, then you must create or identify some commonality and use that to associate or create your own new ID to associate the records.