GlobalID in lowercase from Collector to Survey123 (Windows tablet)

[DSIProvince_Nord]

Hi,

I try to pass a globalID from Collector to Survey via URL parameters. Everything works fine except the GlobalID is always in uppercase in my feature service, but once it goes into an esri.fieldtype:GUID in Survey123, it turns into a lowercase.

I noticed that in iOS, it is passed as an uppercase text, but not in Windows10 tablets (collector and survey123 up-to-date).

The only way I found is to create an "incoming" field with fieldtype=null that stores the value passed by Collector, and then my GUID field that calculate the first AND with InputMask= ">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" to ensure every lowercase letter is set to uppercase.

BUT this only works if the field type in Survey123 (not the esri.fieldtype) is set to "text" AND is NOT readonly AND the user enters into the field (by clicking the field without changing anything) when doing the survey.

This is the only way Survey123 sends Uppercase GUID.

Otherwise, Survey123 is always sending a lowercase GUID.

Any idea ??

[ahargreaves_FW]

This is:

1. Unbelievable.

2. Affecting a workflow we need to work

3. Being escalated by us.

[DougBrowning]

I escalated also 3 years ago and even talked to the team about it in person.  Esri really needs a standards board for the company.

[AaronGlanville]

I wanted to provide another example where this bug causes issues.

My office uses an asset management system that connects work orders to GIS features using the GlobalID. We are currently migrating data to the cloud and thus changing all of the GlobalIDs to lowercase and breaking all connections between the GIS features and years' worth of work orders.

We are currently pursuing a solution with the makers of our asset management system and hopefully will find one shortly. But, this bug points to the larger issue among Esri products that there aren't standards/uniformity across the entire platform.

[Kevin_MacLeod]

I also hope this design issue is resolved. This similar to how AGOL and Portal differ for field names and case (PostgreSQL).  The Esri ecosystem is fragile if you want to change something. These two specific issues are simple but high impact. Perhaps creating a position at Esri like "Enterprise QC Coordinator" to be on the lookout specifically for things that "break" or cause pain points like this would be useful.  They could hold quarterly meetings with leaders from each Support dept and reps from Services, and perhaps even a few customer MVPs. 

[DougBrowning]

I wonder if @MikeBranscomb is on here?  I talked to him in person about it at Dev Summit.  At almost 5 years now, and being escalated 3 years ago, just makes no sense to me as it is a rather major error.  I also talked to each team about it.  

And I agree teams not communicating with other has been a major issue for Esri for a long time.  (To be fair that is true in most companies.)

[MichaelBranscomb]

@DougBrowning Thanks for adding me to the thread, I'll see what I can find out.

[MattSteging]

Any additional information on this issue being corrected? Thanks in advance.

[DougBrowning]

Got me again last week where I had to update some records in Pro, it changed to upper case and broke my relates.

[DougBrowning]

Got this update today.  Of course you cannot change to GUID in 123 land.  They still do not get the problem.

Bug fixes are addressed in upcoming releases or general patches, or they may be addressed as ad-hoc fixes. Enhancement requests are implemented in upcoming releases.

Updates have been made to the following defect which you are associated with:
BUG-000146406 - Inconsistent letter cases for the Global ID values between ArcGIS Desktop and ArcGIS Online products.

Status: Duplicate (Learn More)
Duplicate record #: BUG-000167548
Additional Information: Duplicate of BUG-000167548

Alternate Solution:

For relationship class operations, use a GUID field as the destination key.

Thank You,

[PegGronemeyer1]

@DougBrowning and @MichaelBranscomb 

I've been trying to follow this, but I've only dealt with the related tables of a draft survey - so we have not yet collected data THEN needed to edit in Pro. 

Maybe someone will tell me I'm wrong, (please!), but it sounds like  when our biologists test our survey in the field, it will work at first, but if we try to update a record in Pro - when we actually are dealing with 'real' data, my relates will break???   😱🤯