• Created an action <Entity>_Create that takes input parameter <Entity>Record 
• Created an extension with an action "NewGuid" to  generate a guid value 
• Assigned primary key value with guid value

Would still like to see it implemented.

Any updates on this @Gonçalo Borrêga?

I vote this.

I really would like to have this feature in outsystems, not only for more easy data migration between platforms but also for some kind of extra security layer where users can't not that easy change anymore the url parameters that are currently populated with the generated long integers. 

Is there any chance that OutSystems 11 will get support for a proper way of storing a GUID?

Currently I'd have to store it in a CHAR(32) ; using in the database of at least 2 bytes per character, eating 512 bit's into the database storage and index while Microsoft has the proper hexadecimal storage in the GUID datatype in the database (and index) of 128 bit's.

https://www.sqlshack.com/understanding-the-guid-data-type-in-sql-server/

Some advantages and reasons we need this (and if possible in the proper way)

• The GUID Data type takes up only 1/4th in storage, index and memory.
• A GUID can be provided by external databases and gracefully merged / combined into a central database
• A GUID enables customers / suppliers to communicate through their own references
• This eliminates difficult structures when managing masterdata
• Propagating structures on the change of shared records can be made more generic
  (You could have one big list of the latest version of a GUID and know whether you should refresh it on a remote location improving caching methods)

If this idea is implemented, then there needs to be a way to specify the GUID when bootstrapping data. At the moment you can't bootstrap Id fields if they are autonumber, which is a pain if you have other entities that use the Id as a foreign key.

The manual insert statements work in this but agreed this should be “easy”

Also in lifetime you should be able to manage any static table GUIDs globally imho.

And just let me stress again that native GUID support (so the real database level GUID type too) is very, very important for adoption of event driven tech, workflow and global database scenario’s.

Just a nudge to emphasise again how important GUIDs are for the future of the platform, as well as proper Graph Database support and GraphQL support for both Cloud strategy, performance at scale and integration flexibility.

Also less strong typed structures are limiting the new generation developers to spread their wings with the platform.

Any updates with this? 
The Idea by Beatriz Silva is nice. So you could define your own ID Format, or just use the common uid.

Nudge; a native GUID datatype should have already been implemented in the platform long time ago.

Main reason would be INDEX SIZE and SPEED of the database system.
The query optimizer of MSSQL won't go well on a CHAR(36) which is a GUID including HYPHENS.
In a current database system as VARCHAR that will take up 16 bit's per Character, being 16 x 36 = 576 bit's.

As a native type this would take up 16 Bytes, 128 Bits (over 4 times less), making the search result quicker as well as JOINS over this type.

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/df3caee5-3751-469b-a943-f0c8cb501f75/unique-identifier-vs-varchar36-for-storing-guids?forum=transactsql

From a security perspective using a GUID as Identifier and in query parameters makes it almost impossible to do brute force attack to collect all data.

@Marc Wetters that's why I have switched 100% to them when I moved from Traditional Web to Reactive. Traditional Web made it very easy to prevent certain attacks around the attacker changing IDs. Reactive makes it very easy to accidentally let anyone overwrite any record they want.

J.Ja