Relationship class split policy - Duplicate related objects when origin is a table and destination is polyline feature class

[AnttiRuuskanen1]

We have a one-to-many relationship class where the origin class is a table and the destination class is a polyline feature class. Relationship type in this relationship class is simple. After splitting a polyline feature we would like both new polyline features to be related to the same row in the origin class. However currently this does not happen automatically as relationship class split policy cannot be set to "duplicate related objects" in such relationship class as stated here: Use a relationship class split policy—ArcGIS Pro | Documentation. Why is there such limitation in relationship class split policy and is there any workaround available to achieve the desired result? If not, is Esri going to remove this limitation in the future?

[MobiusSnake]

I'm a little bit confused about the problem here.  The relationship class split policy determines what happens when an origin feature is split, not what happens when a destination feature is split.  From the doc:

The relationship class split policy determines how records in the related destination table are treated when a feature in the origin feature class is split during the editing process.

If you split a destination feature, the newly-created feature should have the same foreign key value as the original, automatically relating that feature to the original table row.  I just created a quick table:polyline relationship to verify this (using Global ID / GUID fields), and splitting a destination polyline resulted in two relationships from the origin table row.

Is there another factor in your scenario, e.g. attribution on the relationship class, attribute rules, or something unusual about your key fields?

[ruuskanen_demo]

I did the same test in file geodatabase, I splitted the destination polyline and only one of the two polyline features (the longer one) has the GUID field populated after the split. If you did your test in file geodatabase, could you share your file GDB?

[ruuskanen_demo]

I'm the same person as the original post sender, it seems that I signed in by using different account as earlier.

[MobiusSnake]

I did it in an FGDB but deleted it immediately after testing, all I did was this though:

• New FGDB
• Create table, add Global ID
• Create polyline FC, add GUID field
• Create relationship class (1:M, composite, forward messaging)
• Create table record
• Create polyline record, set GUID field
• Split polyline record using standard Pro 'Split' interactive tool

[ruuskanen_demo]

Ok, difference was that you were using composite relationship type. I'm using simple relationship type, then the issue occurs.

[AnttiRuuskanen1]

So, when using simple relationships (not composite), is there any solution available? We don't want to use composite relationships.

[VanessaSimps]

Along with that question, what if I have a unique ID (Key) field that isn't a GUID that I need to use? I have a polygon feature and a table that are both populated with data and a user defined unique ID that isn't a GUID for my key fields. Can I not use the duplication split policy now? 

[VanessaSimps]

I was able to create this with a simple: 

You have to have the GUID/GlobalID be the key and you have to change the Split Policy to Duplicate Related Objects. 

[DemouserDemouser]

@AnttiRuuskanen1 Did you find a solution or workaround? I'm facing the same problem..