Flexible Attributes: Letting Your Commerce Data Be Weird (Without Losing It)

Flexible Attributes are custom properties that are not part of Qilin’s core domain models (Product, Order, Offer, etc.) but still matter to real integrations.

Instead of discarding them or forcing them into awkward workarounds, Qilin can store them in a dedicated structure (think: an `options` map) so they can:

• survive ingestion
• flow through pipelines
• be forwarded to destinations that support them
• be enriched, filtered, or transformed when needed

The core philosophy is old-school and practical:

> Don’t lose data you don’t understand yet.

One of the hardest parts of “flexible fields” is the temptation to over-validate.

It sounds responsible to enforce types and constraints, but in real integrations it often becomes a liability:

• different systems define constraints differently
• constraints change over time
• connectors may already validate before sending data
• strict validation in the middle can block otherwise useful workflows

So the platform approach is intentionally pragmatic:

Qilin.Cloud stores flexible attributes and forwards validation metadata—but does not try to re-validate every value.

That keeps Qilin.Cloud compatible across wildly different ecosystems.

Imagine Shopware orders contain a field:

{
  "id": "order_1",
  "orderNumber": "1234",
  "deepLinkCode": "code32543343"
}

If `deepLinkCode` isn’t a native Qilin.Cloud field, the connector can represent it as a flexible attribute:

{
  "id": "order_1",
  "orderNumber": "1234",
  "options": {
    "deepLinkCode": "code32543343"
  }
}

Now the value isn’t lost.

It can be:

• forwarded to another system that supports it
• used in filtering logic
• used to enrich downstream messages
• included in auditing and tracking

Flexible attributes are an “agency feature” even when merchants never hear the term.

Because agencies deal with:

• client-specific customizations
• long-tail requirements
• systems with inconsistent modeling

When flexible attributes are first-class:

• fewer custom connector forks are needed
• implementations become more reusable
• edge cases stop turning into permanent technical debt

This is the kind of platform capability that makes projects easier to deliver – and easier to maintain.

Once flexible attributes are carried reliably, you can do useful things with them:

• filter objects based on a flexible attribute
• enrich objects by calculating new attributes
• map attributes into destination-specific formats

Combined with Filter Predicates, it becomes possible to express business rules like:

• “If `options.deepLinkCode` exists, route to system A, else system B”
• “Only sync offers where `options.partnerTag` is in the allowed list”

Without custom code. Without duct tape.

• Merchants: custom fields stop being “integration killers”. You can evolve your business model without breaking pipelines.
• Investors: flexible attributes reduce per-customer customization cost while increasing platform adaptability – very good leverage.

Flexible data is powerful, but it becomes truly useful when you can process it at scale.

Next month, we’ll cover work around bulk operations and async workflows – how Qilin.Cloud handles big imports without turning your API into a time-out lottery.

The world isn’t tidy.

Commerce data definitely isn’t tidy.

Qilin.Cloud is building toward a platform where “we have one more custom field” isn’t a problem – it’s just Tuesday.