TL;DR
- Customily supports conditional logic — show/hide design elements based on prior selections — essential for non-trivial personalizers.
- Common patterns: garment-color triggers, template-choice triggers, gift-flow triggers, multi-side reveal.
- Where rule sets get gnarly: cross-product rules, customer-upload-content triggers, deep dependency chains.
- Design principles: group rules by 'visible if all of', name rules, test every option combination, audit yearly.
- Same hygiene as options-app rules — see the Hulk conditional logic deep dive for general patterns. Verify Customily-specific capabilities on the listing.
What Customily's conditional logic does well
Customily's conditional logic — like any personalizer's — lets you specify that fields or design elements appear based on prior selections. For personalizer use this is essential because the option space gets complex fast: a Father's Day tee with photo personalization, gift-wrap option, custom message, and conditional gift-recipient details has rules nested several levels deep. Without conditional logic, the customer sees every possible field at once and the form becomes unusable; with it, the form reveals questions as the customer answers prior ones.
Customily's strengths on the rule front align with what personalizers need: template-driven flows (the chosen template determines which fields appear), garment-color triggers (light-fabric templates vs dark-fabric templates), gift-flow triggers (is-a-gift unlocks gift-message and recipient-name), multi-side reveal (front design unlocks 'also customize back?'). See Hulk Conditional Logic Deep Dive for general rule-set hygiene that applies across personalizers and options apps.
Common patterns that work
- Template-choice triggers: customer picks 'Father's Day' template → fields for child names and message appear; 'birthday' template → birthday-specific fields. Clean to model.
- Garment-color triggers: 'dark garment selected' → only light-color text/art options shown (so customers don't pick invisible combinations).
- Gift-flow triggers: 'is this a gift' → gift message field, gift wrap option, optional recipient name field. Standard pattern.
- Multi-side reveal: customizing the front of the garment → option to also customize the back (with its own field set).
- Photo-upload triggers: photo uploaded → photo positioning and adjustment controls appear; no photo → those controls stay hidden.
- Add-on tier triggers: premium tier selection → deeper customization fields unlock.
Where conditional logic gets gnarly
- Cross-product rules: 'if the customer has tee A in cart, change the personalizer behavior on mug B' — typically not what personalizer conditional logic is designed for. Cart-level rules are a different layer.
- Customer-upload-content triggers: 'if the uploaded photo is portrait orientation, show one set of fields; if landscape, show another' — content-detection triggers are limited or not supported by most personalizer rule engines. Verify Customily's specific capability on the listing.
- Deep dependency chains: field D depends on C, which depends on B, which depends on A — works but becomes hard to debug. Flatten where possible.
- Many-to-many conditions: 'show field X if (A=1 AND B=2) OR (C=3 AND D=4) OR (E=5 AND F=6)' — encodable but the rule set rots fast as conditions accumulate.
- Rule conflicts: two rules that touch the same field can silently override each other in order-of-evaluation. Document; don't trust intuition.
Design principles for rules that survive
- Group rules by 'visible if all of A, B, C' rather than scattered single conditions per field. One intent per rule beats five small rules.
- Name rules, even if the app doesn't require names — document each rule's intent in a runbook.
- Flatten dependency chains: prefer 'D depends on A directly' over 'D depends on C depends on B depends on A' when the meaning is the same.
- Test every option combination at setup: enumerate the option matrix and check the personalizer behaves correctly on each path. Tedious; saves support tickets.
- Use mutually exclusive triggers where possible: 'select gift OR self-purchase' is cleaner than two independent checkboxes.
- Audit yearly: retire rules tied to removed templates and consolidate similar rules. Rule rot is real for personalizers, not just options apps.
- Verify the specifics: Customily's exact rule-engine capabilities have evolved — confirm on the current Shopify App Store listing what's supported in the version you're running.
Conditional logic complexity = the right configurator?
If your personalizer's rule set is hitting Customily's limits or feels like it's fighting the system, the question is whether the use case has outgrown personalizer rules entirely. For deep configurator logic, a configurator-first app fits better. For simpler personalization, a flat-fee personalizer with clean rule support fits — Print It My Way, free plan, no per-item fees.
Install Print It My Way — Free Read Customily alternatives →Frequently asked questions
Does Customily support conditional logic?
Yes — conditional logic for showing/hiding fields and design elements based on prior selections is a core Customily capability and essential for any non-trivial personalizer setup. The mechanism supports common patterns like template-choice triggers, garment-color triggers, gift-flow triggers, and multi-side reveal. Verify current rule-engine specifics on the Shopify App Store listing, since feature sets evolve. For general rule-set hygiene principles, the Hulk conditional logic deep dive covers the patterns that apply across both options apps and personalizers.
What are common conditional logic patterns in Customily?
Template-choice triggers (chosen template determines which fields appear), garment-color triggers (dark fabric → only light-color options shown), gift-flow triggers (is-a-gift unlocks gift message and recipient fields), multi-side reveal (front customization unlocks 'also customize back'), photo-upload triggers (photo uploaded → positioning controls appear), and add-on tier triggers (premium tier → deeper fields unlock). These are the workhorses of personalizer rule sets; they cover the majority of personalization configurator needs.
Where does Customily's conditional logic get limited?
Cross-product rules ('if tee A in cart, change mug B behavior') are typically not what personalizer logic is designed for — cart-level rules are a different layer. Customer-upload-content triggers ('if photo is portrait, show different fields than landscape') are limited or unsupported in most personalizer rule engines. Deep dependency chains (D depends on C depends on B depends on A) become hard to debug. Many-to-many condition combinations rot rule sets fast. Verify Customily's specific capabilities on the current listing if any of these edge cases matter for your store.
How do I debug Customily conditional rules?
Same approach as any rule engine. (1) Enumerate the option states that should make the field visible. (2) Check each rule's condition matches that state. (3) Check whether any other rule silently contradicts (showing or hiding when it shouldn't). Customily provides rule visibility within the editor; verify specifics on the listing. The bigger preventive measure is to test every option combination at setup — enumerate the option matrix and walk through each path, confirming the personalizer behaves correctly. Tedious upfront; saves support tickets later when something subtle goes wrong.
How do I keep my Customily rule set maintainable?
Five principles that apply to any personalizer rule engine. (1) Group rules by 'visible if all of A, B, C' rather than scattered single conditions per field — one intent per rule. (2) Document each rule's intent in a runbook even if the app doesn't require names. (3) Flatten dependency chains where the meaning is the same. (4) Test every option combination at setup. (5) Audit yearly — retire rules tied to removed templates and consolidate similar rules. Rule rot is real for personalizers, not just options apps; the audit is what keeps the configurator working in year 3.
When does rule complexity mean I've outgrown personalizer rules?
If your rule set has many cross-product dependencies, deep multi-level chains, or many-to-many conditions that are fighting the personalizer engine, the question is whether the use case has outgrown personalizer rule logic entirely. Two paths: (a) move the deep configurator logic to a configurator-first app (Kickflip) and keep the personalizer for simpler 2D personalization — split the surface area; or (b) simplify the personalizer flow to what the rule engine handles cleanly and move the variant complexity to product-level (different Shopify products for fundamentally different configurations). Most stores find option (b) is what they need — rule complexity often signals a flow that's trying to be too smart.