Skip to main content

Product Updates

See what’s new at our product, check the updates below

Simpler modeling for relationships for object-centric process mining (2024-02-08)

Simpler modeling for relationships for object-centric process mining (2024-02-08) We've redesigned the Objects and Events user interface to give you more guidance when you're modeling custom object to object relationships and event to object relationships:The list of relationships for an object is now divided into outgoing relationships, where the foreign key or join table is to be implemented on this object, and incoming relationships, where the foreign key or join table is to be implemented on the other object. You can click any relationship to view the implementation details and the location of the transformation. You can also show inactive relationships that the object has for processes that you haven’t enabled yet.When you create a relationship between two object types, we now automatically create the relationship in the other direction as well. If you don't want a bidirectional relationship, you can delete it.We've combined the options for the relationship's cardinality with the choice of where and how to handle the relationship data in your transformations, so it's clearer what to choose and what you'll need to do afterwards. Your choices for the cardinality of a custom relationship are now many to one (m:1), one to many (1:m), many to many (m:n) with the relationship table as a join table on the source object, or many to many (m:n) with a join table on the target object. We've removed the choice of a one to one (1:1) relationship, as the object-centric data model and the underlying database don't enforce uniqueness of a foreign key. Any custom one to one relationships already in your object types will continue to exist. For the modeling documentation, see Modeling objects and events. 

Related products:Process Intelligence Graph

Coupa Extractor (2024-01-12)

Coupa Extractor (2024-01-12) Change of primary keys for revision tables Previously the Extractor was using the “id” column as the default primary key for revision tables, which wasn’t right. We’ve corrected it to use the “revision-record_id” column, which means you can properly link and join the parent and child revision tables through this column.Delta loads of the affected child revision tables will fail following this update, because the primary key of the parent table is added in its child table. To prevent this, enable the option Include metadata changes in the extraction settings, or carry out a full data extraction next time in place of a delta load. After that, your delta loads will work correctly again - although you’ll notice a difference in the records they load, because they’re now based on the corrected primary key column.These tables are affected by the primary key change: purchase_order_revisions (parent) and purchase_order_revision_order_lines (child)invoice_revision_records (parent) and invoice_revision_records_invoice_lines (child)order_revision_records (parent) and order_revision_records_order_lines (child)requisition_revision_records (parent) and requisition_revision_records_requisition_lines (child)revision_records_invoiceheader (nested child table of the object)revision_records_orderheader (nested child table of the object)revision_records_requisitionheader (nested child table of the object)