# 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](/components/component-library/modular-checkout-components/managing-conditionality-in-subcomponents.md) 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](/components/component-library/modular-checkout-components/managing-conditionality-in-subcomponents.md), 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](/components/component-library/modular-checkout-components/component-checkout-form.md). 2. **Add subcomponents** (e.g. `Field`, `Address Fields`, `Display Text`) for the extra data you want to collect.\ See [Modular Checkout Subcomponents in Form](/components/component-library/modular-checkout-components/modular-checkout-subcomponents-in-form.md). 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. --- # 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/components/component-library/modular-checkout-components/using-subcomponent-conditions-for-product-specific-data-collection.md?ask= ``` 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.