Using Subcomponent Conditions for Product-Specific Data Collection

With Conditional Subcomponents in the Checkout Form, you can collect extra information only when it’s needed, based on what the customer has in their basket.

This guide shows how to:

Use subcomponent conditions (especially Product in basket) to show or hide fields dynamically
Design product-specific data requirements (e.g. for add-ons or regulated products)
Keep your checkout low-friction while still meeting compliance and operational needs

If you haven’t seen it yet, start with Managing Conditionality in Subcomponents for the feature overview.

1. Typical Use Cases

1.1 Compliance or registration requirements for add-ons

Some add-ons require additional information before they can be provisioned or activated. Examples include:

A messaging / communication add-on that needs business details and declarations
A regulated data add-on that requires confirmation of data protection or privacy policies
An extended warranty that requires extra contact or asset details

In these cases you want to:

Show specific fields when the relevant add-on is in the basket
Hide those fields when the add-on is not selected
Block submission until required fields are completed when the add-on is present

1.2 Product-specific configuration or context

Some products need extra configuration or context at the time of purchase, for example:

A job distribution or posting add-on where you capture job details and targeting criteria
An events product where you capture dates, locations, or audience details
A bundle where certain sub-products require extra eligibility questions

Again, the goal is that these fields only appear when the relevant product(s) are in the basket.

1.3 Channel- or partner-specific data collection

If you sell through multiple channels (direct, reseller, referral, marketplace), different information might be required per channel, such as:

Partner identifiers (e.g. partner account ID, reseller code)
End-customer identifiers needed for downstream provisioning
Eligibility confirmations specific to a partner agreement

You can use conditionality to show channel-specific fields based on which product or offer is being purchased.

2. Key Concept: `Product in basket` Conditions

The Product in basket attribute is the core of product-based conditional data collection.

From Managing Conditionality in Subcomponents, the attribute behaves as follows:

Attribute: Product in basket
Operators: is one of / is not one of
Options: One or more of your configured products
Effect: Controls whether a subcomponent (field, address block, etc.) is visible, depending on the product(s) configured on the offer being purchased.

This means you can:

Tie extra fields to a specific product or add-on
Build re-usable checkouts where fields appear only for relevant products
Maintain a single, flexible flow instead of separate checkouts per product

You can combine Product in basket with other attributes (e.g. Payment method selected, Delivery product in basket, Order price) for more advanced logic.

3. Configuring Product-Based Conditional Fields

3.1 High-level steps

Add the Checkout Form component to your page. See Component: Checkout Form.
Add subcomponents (e.g. Field, Address Fields, Display Text) for the extra data you want to collect. See Modular Checkout Subcomponents in Form.
For each relevant subcomponent, open the Conditions tab.
Add a condition using Product in basket and choose the product(s) that should trigger the field.
Set required / optional and validation rules on those fields.
Rebuild, publish, and test the flow.

3.2 Example: Compliance data for a messaging add-on

Imagine you sell an SMS messaging add-on that requires additional business and compliance information.

Required fields when the add-on is in the basket might include:

Standard business details
- Business / company name
- Registered address
- Tax / registration number
Industry or category selection
- A picklist field to classify the customer’s industry or use-case
Eligibility & compliance confirmations
- Checkboxes confirming specific policy or regulatory requirements
Use-case description
- A free-text field where the customer explains how they intend to use the add-on

You would implement this using one or more Field subcomponents, each with conditions such as:

Product in basket is one of [Messaging add-on product]

All these fields can be marked Required so that the order cannot be submitted unless they are completed, but only when the add-on is present.

3.3 Example: Job posting / distribution add-on

Suppose you have a job posting add-on that sends roles to third-party boards. You may want to capture:

Job title and description
Seniority or job level
Target regions or locations
Job type (full-time, part-time, contract, etc.)

You can:

Add a group of Field subcomponents for these details
Set conditions like:
- Product in basket is one of [Job distribution add-on]
Mark only the truly essential fields as Required to reduce friction

3.4 Example: Reseller / channel identifiers

For orders that come through a reseller or partner network, you might need to collect:

Partner or reseller identifier
End-customer identifier used by the partner
Any specific reference needed for downstream provisioning

If channel-specific offers map to distinct products, you can:

Create Field subcomponents for these identifiers
Add conditions such as:
- Product in basket is one of [Reseller plan A product, Reseller plan B product]

This approach avoids showing reseller-only fields on direct or self-serve flows.

4. Designing Field Sets Per Product

4.1 Start from your business and compliance requirements

For each product or add-on that needs additional data:

List the minimum information required to provision or activate it. E.g. identifiers, eligibility questions, policy confirmations.
Decide which fields are mandatory vs optional.
Define how this data will be used downstream (CRM, billing, provisioning).

Keep the field set as small as possible to reduce friction.

4.2 Re-use field groups across multiple products

Often different products share similar requirements. For example, multiple messaging or communication add-ons might all require the same business details.

You can:

Use the same subcomponent group (or cloned configuration) across related products
Attach multiple products to the same condition using is one of
Keep labels, help text, and validation consistent across flows

4.3 Consider volume- or tier-based products

If a product has volume-based pricing (e.g. units of usage, seats, or messages), you might:

Restrict allowed quantities via the offer configuration
Use additional fields to capture expected usage patterns or key thresholds
Drive downstream configuration (e.g. provisioning limits) from those fields

The conditionality is still based on which product is in the basket, even if that product itself has multiple tiers or pricing levels.

5. Mapping Collected Data to Downstream Systems

While configuration in Limio is no-code, you will usually want the collected data to flow into external systems, such as:

A CRM (account, contact, or opportunity-level fields)
A billing platform (subscription or account custom fields)
A provisioning or activation system

5.1 Align field names and semantics

To make mapping straightforward:

Use clear, consistent Limio field names that reflect their purpose
Avoid reusing the same field name for different meanings across products
Document which Limio fields map to which external fields

5.2 Handle timing and asynchronous integration

If downstream systems read data soon after order creation, be mindful of:

Possible race conditions where the external system reads the order before all fields are populated or processed
The need for retry logic or a slight delay before processing

Good practices include:

Using asynchronous processing or queues in your integration
Implementing idempotent updates so the same order can be safely re-processed
Logging failures related to missing or invalid field values for quick troubleshooting

6. Best Practices for Configuration

6.1 Apply conditions consistently across all channels

If a given product or add-on always requires extra information, ensure the conditional fields are present in all flows where it can be sold, for example:

Direct self-serve pages
Partner or reseller pages
Referral or marketplace flows

This keeps your data and compliance posture consistent, regardless of where the customer buys.

6.2 Use existing forms and checklists as templates

If your organisation already uses forms, spreadsheets, or checklists for a product:

Use them as a starting point for the fields you add to checkout.
Keep the same terminology and naming where possible, so internal teams immediately recognise the data.
Mirror any validation rules that are business-critical (e.g. format of IDs, mandatory declarations).

6.3 Minimise friction for non-affected products

A key benefit of subcomponent conditions is that they remove unnecessary fields when the product is not present.

Confirm that conditional fields disappear cleanly when a product is removed from the basket
Avoid collecting sensitive or complex data where it is not strictly needed
Use concise labels and help text to make conditional fields easy to understand when they appear

7. Testing & Validation

To be confident your configuration behaves as intended, test across three dimensions: visibility, validation, and data flow.

7.1 Conditional display testing

Add each trigger product to the basket one by one, and confirm that:
- The expected conditional fields appear
- Fields tied to other products do not appear
Remove the product from the basket and verify the fields disappear again
Verify that non-conditional checkouts (for unrelated products) remain uncluttered

7.2 Validation behaviour

With the trigger product in basket, attempt to submit the checkout with required conditional fields empty:
- Confirm you see clear validation messages
- Confirm submission is blocked until all required fields are filled
With the product not in the basket, ensure that the same required fields do not block the order (because they are not shown).

7.3 End-to-end data flow

If you have integrations to external systems:

Place a test order for each relevant product or add-on
Verify that each conditional field value appears in the correct external fields
Confirm that any asynchronous or delayed processing still receives the correct values
Check logs or dashboards for any mapping or validation errors

Where possible, run at least one full production-like test to confirm that live connections, provisioning, and reporting all work as expected.

8. No-Code Configuration & Copy Control

One of the strengths of Limio’s Conditional Subcomponents is that everything is configured via the UI—no code changes are required.

Using the Checkout Form and subcomponents, you can:

Add or remove conditional fields per product or add-on
Adjust which fields are required vs optional
Update validation rules and error messages
Change labels and help text to match evolving compliance or operational requirements

Because labels, helper text, and error messages are editable, you can:

Tailor messaging for different regions or audiences
Clarify why you are asking for specific information
Keep your checkout copy aligned with legal or policy wording without developer involvement

9. Implementation Checklist

Use this checklist when setting up product-based conditional fields:

Identify trigger products that require extra data collection (e.g. a messaging add-on, job posting add-on, or partner plan).
Define the minimum required fields for each product, based on compliance and operational needs.
Configure subcomponent conditions using Product in basket to show those fields only when the relevant product is present.
Mark fields as required where appropriate and configure validation (length, regex, etc.).
Map Limio fields to downstream systems (CRM, billing, provisioning) and document those mappings.
Test all flows (direct, partner, reseller, referral) where the product can be sold, checking visibility, validation, and data flow.
Monitor and iterate based on real orders, tightening or relaxing field sets as needed to balance compliance and conversion.

By combining Conditional Subcomponents with thoughtful field design, you can keep your checkout streamlined for most customers while still collecting all the specialised data you need for specific products and add-ons.

PreviousModular Checkout: How to configure a gift checkout?NextCart Components

Last updated 17 days ago

Was this helpful?

Good morning