Version 3

SyncHive V3 introduces a range of improvements to how data is exchanged and managed. From simplified, flexible shapes to new schema querying and customization tools, it’s designed to support the next generation of knowledge workers as they build the future.

The version delivery date: May 2025

Data Model & Structure

1. Introduction of Entities

What changed:

In V3 we clarified and distinguished the concepts of entities and shapes.

An Entity is a representation of a real-world object or concept, capturing everything known about it across all contexts. It serves as a comprehensive and consistent source of truth, integrating data from multiple systems and domains.

For example, a Patient entity will include identification data, demographics and other attributes that describe the patient regardless of any context.

A Shape describes everything we are interested in about a real-world object or concept in a specific context. While entities represent the full scope of a concept, a shape reflects how that concept (or combination of concepts) is understood or used in a particular scenario.

For example, a Patient Shape may combine data from the Patient, Clinical History, Insurance Details.

Value delivered by the improvement:

1. Clearer mental model for each user role:

• Data Designer to model reusable, system-agnostic entities.
• Connector Builder to build context-specific shapes for connectors.
• Power User to get consistent, trustworthy data in their tools.

2. Reusable building blocks: Entities support multiple shapes, cutting down duplication and ensuring consistency across workflows.
3. Easier to maintain: Entities stay stable. Shapes can evolve independently as integration needs change.
4. Real-world fit: Shapes can combine multiple entities—perfect for modeling real processes like claims, onboarding, or account syncs.

Examples:

Entity: Customer

This entity includes properties to capture core data of a specific customer, identified by entityId:

entityType: Customer
entityId: cust-123
name: Acme Corporation
industry: Manufacturing
createdDate: 2024-01-15

Shape: CustomerAccountProfile

This shape represents how this customer appears in the context of an account profile. It includes:

• Core customer properties: name, industry
• Role and permission information from related Account or User entities
• Profile creation and status metadata from other systems

2. JSON Structure

What changed:

In V2, shapes used a semantic, nested, and typed model - data was organized in complex object hierarchies that were harder to parse, query, and extend.

In V3, shapes follow a flattened, key-driven, denormalized structure—nested objects are replaced with a simplified structure of properties or value arrays, making the data model leaner and easier to work with.

Value delivered by the improvement:

• Improves performance by eliminating nested parsing and enabling simpler queries.
• Simplifies data access for SyncHive power apps and integrations.
• Enhances flexibility to add or modify fields without complex restructuring.
• Makes data clearer and more explicit, reducing interpretation overhead.

Examples:

Buyer references:

V2:

"buyer": { "@type": "InternalReference", "id": "...", "className": "BusinessPartner", "externalIdentities": [...]}

V3:

"buyer_externalId": ["1000611"]
"buyer_primaryName": "..."
"buyer_hiveId": "..."

3. Attribute Values

What changed:

In V2:

• An attribute (like productType, productGroup, etc.) is represented as an attributeField object.
• Inside an attributeField, there's an array of attributeValue objects — which are references to external values, using @type, schemaName, shapeName.
• These references include:
  • links to external schemas
  • optionally, multiple external IDs for integration systems
  • a keys array for internal codes or unique text

Drawbacks of this implementation:

• Verbose and nested — lots of indirection and unnecessary abstractions
• Harder to work with for non-developers or general business users
• Painful to query or debug

In V3:

• Indirections are flattened
• Instead of having AttributeField and attributeValue, each concept like ProductType is now broken into explicit, readable properties:
  • productType_code: e.g. "EEV"
  • productType_description: e.g. "The most powerful toaster on the Romanian market."
  • productType_externalId: e.g. ProductType:"EEV" - which still supports cross-system identity
• If there's no value (like for ProductModel), it’s just null or [], keeping things simple and explicit.

Value delivered by the improvement:

• Simplicity & clarity — no need to look up external schemas or resolve references to understand the value.
• Better for integrations — systems can map directly to fields like productTypeCode or productTypeExternalId.
• Still extensible — if you need to track external IDs for multiple systems, you still can (in the externalId arrays).

Examples:

V2 attributeValue:

{
  "name": "Power Toaster",
  "attributeField": [
    {
      "@type": "attributeField",
      "key": "ProductGroup",
      "attributeValue": [
        {
          "@type": "dataReference",
          "schemaName": "example",
          "shapeName": "attributeValue",
          "iri": "https://example.org/schema/attributeValue#123456"
        }
      ],
      "uniqueText": "group-uuid-1"
    },
    {
      "@type": "attributeField",
      "key": "productType",
      "attributeValue": [
        {
          "@type": "dataReference",
          "schemaName": "example",
          "shapeName": "attributeValue",
          "iri": "https://example.org/schema/attributeValue#987654",
          "externalIdentities": [
            {
              "integrationKey": "SystemA",
              "externalId": "productType::GEN1"
            },
            {
              "integrationKey": "SystemB",
              "externalId": "productType::GEN1"
            }
          ],
          "keys": [
            {
              "code": "GEN1",
              "discriminant": "productType"
            },
            {
              "uniqueText": "product-type-uuid"
            }
          ],
          "label": "Nuclear Power Toaster"
        }
      ],
      "uniqueText": "product-type-uuid-outer"
    },
    {
      "@type": "attributeField",
      "key": "productModel",
      "attributeValue": [],
      "uniqueText": "product-model-uuid"
}

V3 attributeValue:

{
  "name": "Power Toaster",
  "productGroup_externalId": ["ProductGroup::10000001"],
  "productGroup_code": "10000001",
  "productGroup_description": "Sample Description",
  "productType_externalId": ["ProductType::EEV"],
  "productType_code": "EEV",
  "productType_description": "The most powerful toaster on the Romanian market.",
  "productModel_externalId": [],
  "productModel_code": null,
  "productModel_description": null
}

V3 SalesOrder creating a product:

{
  "hiveId": "B7D69238056E",
  "salesOrderItem": {
    "hiveId": "976D625B045E",
    "catalogItem_hiveId": "E8B4B1AA3B05" // Product is auto-created if missing
  }
}

4. Schema Extension Capabilities

What changed:

How the data model supports new properties being added as businesses evolve or different tenants need variations. This is about enabling extensibility at the schema level - letting us evolve the model in a controlled, visible, and scalable way.

In V2 there was a rigid model with generic key-value pairs.
In V3 there is a structured, schema-driven way to add extensions, defined centrally.

Value delivered by the improvement:

• More user control.
• Central visibility of extension properties.
• Supports evolving business needs.
• Makes the model more flexible.
• Helps scale in multi-tenant or multi-domain systems.

Examples:

The extendedBy array in the SalesOrder structure:

V2:

"extendedBy": [{ "key": "division", "value": ["03"] }]
"key": "distributionChannel", "value": ["10"]

V3:

"ext_division": "03"
"ext_distributionChannel": "10"

5. Extension Properties (implicit → explicit)

What changed:

How extension data is represented and stored in records - specifically the move from generic arrays to clearly named properties.

In V2 there were dynamic key-value arrays.
In V3 there are explicit, named properties like ext_division.

Value delivered by the improvement:

• Easier to access and query.
• Improves performance (no need to iterate through an array).

Examples:

V2 implicit example of extendedBy array:

"extendedBy": [
  {
    "key": "division",
    "value": ["03"]
  },
  {
    "key": "masteredBy",
    "value": ["SapS4"]
  }
]

V3 explicit / direct properties:

"ext_division": "03",
"ext_masteredBy": "SapS4"

6. Entities and shapes edited by the user

What changed:

This feature is not fully functional yet, it will be delivered soon.

Users can edit entities and shapes directly in the user interface, adapting them to their specific needs without SyncHive support team's help.

Value delivered by the improvement:

• Increased user flexibility and freedom.

7. New Customer Model & Schema

What changed:

In V2, there were no entities - CustomerAccount was just a shape representing a buyer - seller relationship. Business partners (buyers or sellers) were tied to individual CustomerAccount, and their data wasn’t shared or synced across customer accounts.

In V3, entities were introduced to improve integration and flexibility. Customer is now an entity that owns multiple customer accounts. BusinessPartner was split out and renamed to Party, a standalone entity that can relate to multiple customer accounts.

Value delivered by the improvement:

• Consistent data updates – shared party data updates across all linked customer accounts.
• Flexible integration – new entity model supports complex relationships and easier integration.
• Clearer structure – separates concepts for better maintainability.

Examples:

In V2, if the same buyer operated in two locations, they were represented by two separate customer accounts with no shared data.

In V3, that buyer is a single party linked to multiple customer accounts - when the party is updated, the change is reflected in all related customer accounts.

Identifiers

8. ID Resolution

What changed:

In V2 we could use any integration’s external ID. We used the properties: uniqueText and externalIdentities

In V3, ID resolution is standardized using explicit properties: hiveId, externalId, and alternateKey.

• We restricted the use of other integration external IDs
• For inbound/outbound, externalId refers to the integration-specific ID
• In Explore, you can toggle between the integrations to see the relevant external Ids

Value delivered by the improvement:

• Unifies data from multiple systems.
• Prevents duplicates and inconsistencies.
• Improves analytics and decision-making with a complete view.
• Enables accurate joins and relationships in your unified data model.

9. HiveID Format, Uniqueness & Generation

What changed:

In V2, HiveIDs were called uniqueText and used standard UUIDs (e.g., 0000af8c-92dd-4b18-9f38-0009982b6a7c). These IDs were globally unique but lacked readability and consistency with SyncHive conventions.

In V3, HiveIDs use a custom format: 12-character alphanumeric strings (0–9, A–F), e.g., 7CAFD0B0DF22. They are unique within each SyncHive instance.

Additionally, V3 introduces a dedicated API to generate HiveIDs—ideal for integration scenarios that require pre-assigned IDs.

Value delivered by the improvement:

• Cleaner format – shorter, consistent IDs that fit SyncHive conventions.
• Instance-level uniqueness – simplifies sandbox/test environment management.
• ID generation support – enables advanced integration workflows.

Examples:

V2 HiveID: 0000af8c-92dd-4b18-9f38-0009982b6a7c

V3 HiveID: 7CAFD0B0DF22

10. Alternate Key Identification & Setting

What changed:

In V2, alternate keys were identified by the SyncHive schema.

In V3, users define their own alternate keys based on what’s unique in their data. They can choose core fields or even extension properties as alternate keys, giving them full control.

Value delivered by the improvement:

• Flexible matching – link and match records using familiar, human-readable IDs.
• Better integrations – ideal for scenarios where external systems don’t use HiveIDs.
• Improved data quality – easier to spot duplicates and enforce uniqueness rules.

Examples:

In V3, if a code is unique for your organization, you can tag it as an alternate key.

Improved Data Ingestion Flexibility

11. No Mandatory Fields & Missing Data Auto-Creation

What changed:

In V2, mandatory properties were required for data input. If any dependent mandatory data was missing (e.g., a required product for a sales order), the entire data submission was rejected.

In V3, the concept of mandatory properties is removed, except for IDs. If dependent data is missing, it is automatically created to ensure smooth data flow.

Value delivered by the improvement:

• More data flows in: prevent rejection over small issues.
• Handles diverse sources: accepts different formats.
• Boosts stability: fewer failures in inbound integration.

Examples:

In V2, submitting a SalesOrder without a linked Product would result in an error like:

Missing mandatory property accountCode of class CustomerAccount in shape CustomerAccount.

In V3, a SalesOrder with only an ID is accepted. If Product data is missing, SyncHive automatically creates it. No error is displayed, ensuring seamless data integration.

Data Deletion

12. Default delete pattern

What changed:

In V2, the system only supported hard deletes, records were permanently removed from the system.

In V3, we moved to soft delete as the default delete pattern. Hard deletes will soon be available as an alternative option. Deleting rules in V3:

• Deleting the parent component of an entity record also marks all its child components as deleted.

• Reviving the parent component of an entity record does not automatically restore its child components.

• The behavior for handling child components of deleted records (e.g., arrays) during updates depends on the TargetShapeMergeAction setting:

  Merge: Keeps existing child components of a record not in the incoming data. Replace: Removes all child components of a record not in the incoming data.

• Each component of an entity has the isDeleted flag.

• By default, if the flag is not set, it is considered false (i.e., the record is active).

• When isDeleted = true, that component of the record remains stored but is logically removed from active use.

• The isDeleted property can be included in shapes, just like any other property.

Value delivered by the improvement:

• Data persistence – data is never permanently lost, ensuring it can be audited, recovered, or debugged when needed.
• Safer operations – reduces the risk of accidental permanent deletion by allowing records to be logically removed and restored.
• Cascading logic – automatically handles child records when a parent is deleted, ensuring consistent data integrity.

Examples:

Product has a reference to ProductPlant as an array.

When Product is deleted, all ProductPlant records are marked as deleted.

If the TargetShapeMergeAction is set to "Replace":

• The child records (e.g., ProductPlant) are fully replaced with the incoming data.
• Any ProductPlant records that are not included in the incoming message will be deleted.

For example, if the current Product has 3 product plant records, but the incoming update only specifies 2 of them, the third (which is not in the incoming data) will be deleted.

Integration Logic & Outbound Messages

13. Inbound Shape Can Trigger Multiple Outbound Shapes

What changed:

In V2, each inbound shape could only trigger a single outbound shape.

In V3, users can configure which outbound shapes should listen for updates from specific inbound shapes, enabling greater flexibility in managing data flows.

Value delivered by the improvement:

• More flexible integration – multiple related updates can now be processed in a single flow, improving data synchronization across systems.
• User-driven configuration – users have full control over which updates trigger outbound messages, offering more customization.

Examples:

If a SalesOrder is updated with new customer and product data, outbound messages for both Customer and Product can be triggered simultaneously.

14. Suppressing Redundant Messages

What changed:

In V2, a message was sent every time a shape update was published in the system, regardless of whether the entire shape had changed.

In V3, messages are only sent for the pieces of data that have actually changed. If no data has changed, no message will be sent for the shape.

Value delivered by the improvement:

• Smaller, more efficient messages – reduced processing load.
• Less noise - easier to track changes.

Examples:

In V2, whenever a product price changed, the entire product shape was sent.

In V3, only the updated price is sent, reducing unnecessary data transfers.

New UI Features

15. Hive Explorer & Searching & Filtering

What changed:

• Hive Explorer displays all entities and shapes.
• The user can search for and filter shape data with multiple filters at once.
• The user can see multiple records in a customizable tabular format.

Value delivered by the improvement:

• Makes the data model easier to understand and work with.
• Helps users find and use the right data faster.

Examples:

Hive Explorer entity list:

V2 the filtering feature:

Filtering in V3:

16. Built-in Data Dictionary

What changed:

A new feature was implemented: viewing a JSON description with sample values of the shape properties.

Value delivered by the improvement:

• Clarity – explains what each property means and how to use it.
• Consistency – ensures everyone uses the data the same way.
• Faster development – helps developers and analysts build or query with confidence.

Examples:

documentNumber: Unique identifier for the billing document. e.g. INV-2025-0456
billingDate: Date the invoice was issued. e.g. 2025-05-01
customerName: Display name of the billed customer. e.g. Example Corp
totalAmount: Total amount before tax. e.g. 12500.00, currency: USD
taxAmount: Total tax amount applied to the billing document. e.g. 875.00
grandTotal: Total after tax. e.g. 13375.00
status: Current state of the billing document. e.g. Issued
paymentTerms: Payment conditions or contract terms. e.g. Net 14

Deprecated Features

17. Removal of Stores and Sandbox

What changed:

In V2, there was the capability to support multiple data stores. Each data store had a sandbox and a live mode.

In V3, there is one Unified Data Store per environment.

Value delivered by the improvement:

• Simpler setup and less manual work – faster, cleaner configuration.
• Clearer flow – easy endpoint verification and management.
• Simplified user interface.

Examples:

In V2 there’s a user interface component where you can view and configure each Store:

In V2 there is a sandbox of live connection to each store:

In V3 there is no concept of stores and each connector has one contact (configurable by the user):

Coming soon

Hard Delete Functionality

Is no longer the default delete behavior in V3, but will soon be available as an alternative action where there is no value for the user in retaining the deleted data.

Create Entities & Shapes

In V3 the user will be able to edit the existing entities and shapes, but not create the new ones.

Allowing users to create entities and shapes offers:

• Greater flexibility – users can tailor data models to fit their specific business needs.
• Faster adaptation – enables quick adjustments as business requirements evolve.
• Increased control – users can make changes independently, reducing dependency on developers
• Improved alignment – custom entities ensure better mapping to internal business processes and data structures.

Labels

Labels (currently not available in V3) will be reintroduced shortly.