# Guide: Using Conditions in the Checkout 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](https://docs.limio.com/components/component-library/modular-checkout-components/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](https://docs.limio.com/components/component-library/modular-checkout-components/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](https://docs.limio.com/components/component-library/modular-checkout-components/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](https://docs.limio.com/components/component-library/modular-checkout-components/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. Designing Field Sets Per Product

#### 4.1 Start from your business and compliance requirements

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

1. **List the minimum information** required to provision or activate it.\
   E.g. identifiers, eligibility questions, policy confirmations.
2. Decide which fields are **mandatory vs optional**.
3. 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

### 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) such as [https://docs.limio.com/integrations/salesforce-integrations](https://docs.limio.com/integrations/salesforce-integrations "mention")
* A **billing platform** (subscription or account custom fields) such as [https://docs.limio.com/integrations/zuora-integration](https://docs.limio.com/integrations/zuora-integration "mention")
* A **provisioning or entitlement 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:

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

#### 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:

1. **Identify trigger products** that require extra data collection (e.g. a messaging add-on, job posting add-on, or partner plan).
2. **Define the minimum required fields** for each product, based on compliance and operational needs.
3. **Configure subcomponent conditions** using `Product in basket` to show those fields only when the relevant product is present.
4. **Mark fields as required** where appropriate and configure validation (length, regex, etc.).
5. **Map Limio fields** to downstream systems (CRM, billing, provisioning) and document those mappings.
6. **Test all flows** (direct, partner, reseller, referral) where the product can be sold, checking visibility, validation, and data flow.
7. **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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.limio.com/guides/feature-implementation-guides/guide-using-conditions-in-the-checkout-for-product-specific-data-collection.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.