Use Survey 123 Connect to Collect GPS tracker Installation Data

[JeffSilberberg]

I am starting to build a new Survey 123 Connect that will be used to document what vehicles a GPS tracking device will be installed in.  The Primary Key to the resulting Feature Layer needs to be the IMEI of the Device, the Secondary Key will be the Vehicle ID.  I plan to use Connect so I can scan the Bar Code IMEI on each device. 

Since I want this to be a collection tool I do not plan to use the inbox.  But how do I control the issue of a potential duplicate primary key if a unit is moved from vehicle one to vehicle two and rescanned/inputted twice into the system? 

TIA - -

[abureaux]

There are a ton of ways you could handle this, but hard to say what is best for your business case. How will you be ingesting this data? I assume there are more steps to this process beyond getting the data into Esri?

We have a brand new fleet that will need a similar system soon.  These were the top two things that came to my mind when i was thinking of this same thing:  

• I’d probably use SharePoint and Power Automate, and essentially ignore Esri’s database. Mainly because our H&S team would want the info to be readily accessible, and Power Automate would give the needed flexibility.  I’d probably also make it vehicle-centric, but from your description, I assume you have a vehicle database already, and this new one is almost a relational database? 
•  You could use the Inbox. Pre-fill with all of the IMEIs and don’t let people collect new data. Then they just edit each tracker, so it doesn’t matter if it moves vehicles. The issue with this one is you then have ‘missing’ vehicles if a tracker moves. But again, I assume you have a separate database for vehicles? 

[JeffSilberberg]

Thank you for the reply -- 

Yes, there are a ton of different ways to handle this, but for this new install/fleet of trackers, I have 66 devices so the inbox is just much too cumbersome.   If this was a Web Page I would get the IMEI (Primary Key here), do a look on the DB, and if it's already present populate the form and treat the submit as an update instead of an insert.  That's what I would like to do here, treat any submit with an existing key as an update.  

Instead, right now, I think I will place a Webhook on the submit and then use the rest API to delete any older entries for the same primary key from the target of the Webhook.  

Using this data to enrich the transactions coming in through the feed in velocity will be straightforward with a join node using the IMEI as the common key. 

[JeffSilberberg · Accepted solution]

Just a quick update -- 

   I went with the Webhook approach and maintained the Feature layer and a separate PostgreSQL table.    

   ---