Using Subcomponent Conditions for Product-Specific Data Collection

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

1. Add the Checkout Form component to your page. See Component: Checkout Form.

2. Add subcomponents (e.g. Field, Address Fields, Display Text) for the extra data you want to collect. See Modular Checkout Subcomponents in Form.

3. For each relevant subcomponent, open the Conditions tab.

4. Add a condition using Product in basket and choose the product(s) that should trigger the field.

5. Set required / optional and validation rules on those fields.

6. 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. Best Practices for Configuration

4.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.

4.2 Use existing forms and checklists as templates

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

1. Use them as a starting point for the fields you add to checkout.

2. Keep the same terminology and naming where possible, so internal teams immediately recognise the data.

3. Mirror any validation rules that are business-critical (e.g. format of IDs, mandatory declarations).

4.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

5. Testing & Validation

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

5.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

5.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).

5.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.