Skip to main content
Workflows allow you to orchestrate complex enrichment processes by defining dependencies between attributes. When you run an enrichment with multiple attributes, Cernel automatically orders them based on their dependencies, ensuring that foundational attributes are generated before dependent ones.

​
What Are Workflows?

A workflow defines relationships between attributes in your taxonomy. During an enrichment run, Cernel analyzes the dependencies of the requested attributes and generates an execution order that respects those dependencies. Key Concepts:
  • Define dependencies between attributes in a taxonomy
  • During enrichment, only attributes in the request are considered
  • The system automatically orders execution based on the dependency graph
  • Dependencies enable context-aware, multi-stage content generation
When you enrich attributes [A, B, C], Cernel orders them based on their defined dependencies. If C depends on B, and B depends on A, they’ll execute as: A → B → C.

​
How Dependencies Work

Dependencies work on two independent axes that control different aspects of workflow behavior:

​
Axis 1: Dependency Type (Required vs Optional)

What happens when a dependency has no value?

Required Dependencies

Fails if dependency value is not setThe dependent attribute will fail if the required dependency ran but produced no value or failed to generate data.

Optional Dependencies

Continues even if dependency value is not setThe dependent attribute continues regardless of whether the dependency has data. It will use whatever is available.

​
Axis 2: Inheritance Mode (Inherited vs In-Group)

What happens when a dependency is not in the enrichment request?

In-Group Dependencies

Must include all dependencies in enrichment setIf attribute A depends on B (in-group), you MUST include both A and B in your enrichment request, or A will be skipped entirely.

Inherited Dependencies

Can skip dependencies not in enrichment setIf attribute A depends on B (inherited), A will still run even if B is not in the enrichment request. The dependency is optional at the request level.

​
Combining the Two Axes

These two axes are independent and combine to create four possible configurations:
ConfigurationDependency Not in RequestDependency Runs But No Value
Required + In-GroupDependent attribute skippedDependent attribute fails
Optional + In-GroupDependent attribute skippedDependent attribute continues
Required + InheritedDependent attribute runsDependent attribute fails
Optional + InheritedDependent attribute runsDependent attribute continues

​
In-Group Dependencies

In-group dependencies are defined between attributes within a taxonomy. They enforce strict dependency constraints: all dependencies must be included in the enrichment request.

​
Characteristics

  • Defined directly within a taxonomy/group
  • Strict enforcement: Dependent attributes are skipped if dependencies are not in the enrichment set
  • Ensures complete workflows when all required attributes are present
  • Best for workflows where dependencies are critical
If attribute A has an in-group dependency on attribute B, you MUST include both A and B in your enrichment request, or A will be skipped.

​
How to Define In-Group Dependencies

1

Define Attributes

Create attributes in your taxonomy (e.g., Color, Material, Description)
2

Set Dependencies

For each attribute, define which other attributes it depends on within the taxonomy. Mark each dependency as required or optional.
3

Run Enrichment

When enriching, include all attributes and their dependencies in your request. Cernel will execute them in dependency order.

​
Example: Fashion Products Workflow

A typical fashion product workflow might look like: 
Stage 1: Basic Attributes
├── Color Detection Agent
├── Material Identification Agent
└── Style Classification Agent
        ↓
Stage 2: Dependent Content
├── Product Description Agent (uses color, material, style)
└── SEO Meta Description Agent (uses description)
        ↓
Stage 3: Compliance & Organizational Context
├── Regulatory Compliance Agent (validates against brand guidelines)
├── Content Policy Agent (ensures organizational standards)
└── Market-Specific Requirements Agent (applies regional rules)
Circular dependencies are not allowed. Ensure your workflow has a clear start and end point.

​
Setting Up In-Group Dependencies

Define dependencies between attributes in your taxonomy:
  1. Navigate to your taxonomy configuration
  2. For each attribute, specify which other attributes it depends on
  3. Mark each dependency as:
    • Required or Optional (controls behavior when dependency has no value)
    • In-Group (must include all dependencies in enrichment requests)
  4. Save your configuration
When creating enrichment requests, the UI will show you which dependencies are required for each attribute to help you include all necessary attributes.

​
Example: In-Group Dependencies with Required vs Optional

Scenario: Description depends on Color (required) and Material (optional), both as in-group dependencies. ❌ Missing dependency - Description is skipped: 
Enrichment Request: [Color, Description]
Dependencies: 
  - Description depends on Color (required, in-group)
  - Description depends on Material (optional, in-group)
Result: Description is SKIPPED (Material not included in request)
✅ All dependencies included: 
Enrichment Request: [Color, Material, Description]
Dependencies: Same as above
Scenario A: Color = "Blue", Material = "Cotton"
Result: Color → Material → Description (all run successfully)

Scenario B: Color = "Blue", Material = (failed/no value)
Result: Color → Material (failed) → Description (continues anyway, Material is optional)

Scenario C: Color = (failed/no value), Material = "Cotton"
Result: Color (failed) → Description FAILS (Color is required)

​
Use Cases for In-Group Dependencies

When you need to ensure all steps in a workflow are executed together, use in-group dependencies. This prevents partial workflows from running.
Define different dependency structures for different product categories by creating separate taxonomies with different in-group dependencies.
When enriching in batches, use in-group dependencies to ensure each batch includes all necessary attributes for complete processing.

​
Inherited Dependencies

Inherited dependencies provide flexibility by allowing attributes to run even when their dependencies are not included in the enrichment request. The dependent attribute will simply skip the missing dependencies and proceed with whatever data is available.

​
Characteristics

  • Dependencies can be defined on the taxonomy but marked as “inherited”
  • Flexible execution: Dependent attributes run even if dependencies are missing from the enrichment set
  • Missing dependencies are skipped automatically
  • Best for workflows where dependencies enhance quality but aren’t mandatory
If attribute A has an inherited dependency on attribute B, A will still run even if you only request [A]. The dependency B is automatically skipped if not in the request.

​
How Inherited Dependencies Work

When you define a dependency as inherited:
  1. Dependency in request: Executes normally in dependency order
  2. Dependency not in request: Skipped automatically, dependent attribute still runs
  3. Dependency fails/no value:
    • If required: Dependent attribute fails
    • If optional: Dependent attribute continues

​
Inheritance Hierarchy

Products can inherit dependency configurations from collections: 
Collection-Level Dependencies
        ↓
Product inherits configuration
        ↓
Optional Product-Level Overrides
Use inherited dependencies for flexible, ad-hoc enrichments where you want to enrich different attribute combinations without being constrained by strict dependency requirements.

​
Example: Inherited Dependencies with Required vs Optional

Scenario: Description depends on Color (required, inherited) and Material (optional, inherited). ✅ Partial enrichment works: 
Enrichment Request: [Color, Description]
Dependencies:
  - Description depends on Color (required, inherited)
  - Description depends on Material (optional, inherited)
Result: Color → Description (Material automatically skipped since not in request)
✅ Full enrichment with all attributes: 
Enrichment Request: [Color, Material, Description]
Dependencies: Same as above
Scenario A: Color = "Blue", Material = "Cotton"
Result: Color → Material → Description (all run successfully)

Scenario B: Color = "Blue", Material = (failed/no value)
Result: Color → Material (failed) → Description (continues, Material is optional)

Scenario C: Color = (failed/no value), Material = "Cotton"
Result: Color (failed) → Description FAILS (Color is required, even though inherited)
✅ Enriching only description: 
Enrichment Request: [Description]
Dependencies: Same as above
Result: Description runs (both Color and Material skipped since not in request)
Inherited dependencies provide maximum flexibility. You can enrich any subset of attributes, and the system will use whatever dependencies are available in the request.

​
When to Use In-Group vs. Inherited Dependencies

Use In-Group When...

  • Strict enforcement: all dependencies must be present
  • Running complete, structured workflows
  • Dependencies are critical to quality
  • Batch processing with consistent attribute sets

Use Inherited When...

  • Flexibility: allow partial enrichments
  • Dependencies enhance but aren’t mandatory
  • Ad-hoc enrichments with varying attributes
  • Different products need different combinations

​
Product-Level Configuration

Products inherit dependency configurations from their collections, but you can override settings at the product level when needed: When to override:
  • Products with unique enrichment requirements
  • Testing new dependency configurations
  • Special cases or premium products with different workflows
  • One-off enrichments with custom needs

​
Best Practices

Use in-group for strict, complete workflows. Use inherited for flexible, partial workflows. Don’t mix modes unless you have a specific reason.
Use required when output quality depends critically on the dependency. Use optional when the dependency enhances quality but isn’t mandatory.
When using in-group dependencies, always include all dependent attributes in your enrichment request, or the dependent attribute will be skipped.
Inherited dependencies enable flexible testing. You can enrich just one attribute without worrying about missing dependencies.
Never create cycles (A depends on B, B depends on A). The system will reject circular dependency graphs.
Clearly document why you chose in-group vs inherited, and which dependencies are required vs optional. This helps your team understand the workflow logic.

​
Workflow Execution

​
How Workflows Run

When you start an enrichment with multiple attributes, Cernel automatically:
  1. Analyzes Dependencies: Examines the dependency graph for the requested attributes
  2. Generates Execution Order: Creates an order that respects all dependencies
  3. Applies Inheritance Rules:
    • In-group: Skips dependent attributes if dependencies are missing
    • Inherited: Skips missing dependencies, runs dependent attributes anyway
  4. Executes in Order:
    • Independent attributes run in parallel
    • Dependent attributes wait for prerequisites
    • Failed dependencies trigger required dependency failures

​
Execution Order Example

Given these dependencies: 
- Style depends on Color, Material (in-group, required)
- Description depends on Style, Brand (inherited, optional)
- SEO_Meta depends on Description (in-group, required)
Enrichment Request: [Color, Material, Style, Description, Brand, SEO_Meta] Execution Order: 
Stage 1: Color, Material, Brand (no dependencies, run in parallel)
Stage 2: Style (waits for Color, Material)
Stage 3: Description (waits for Style, uses Brand if available)
Stage 4: SEO_Meta (waits for Description)

​
Monitoring Workflow Progress

Track workflow execution in the Jobs dashboard:
  • View execution order and current stage
  • Identify which attributes are waiting for dependencies
  • See failure reasons (missing required dependency, etc.)
  • Analyze execution time per stage
Learn more about job monitoring →

​
Common Workflow Patterns

Sequential Pipeline

Basic → Intermediate → Advanced attributes in strict order

Fan-Out Pattern

One base agent feeds multiple dependent agents in parallel

Multi-Stage Generation

Generate structured data, then content, then SEO

Conditional Workflows

Different paths based on product characteristics

​
Troubleshooting Workflows

Issue: An attribute didn’t run during enrichment.Causes:
  • In-group dependency missing: If the attribute has in-group dependencies, all dependencies must be in the enrichment request.
  • Already has value: Some enrichments skip attributes that already have values.
Solution: Check the job logs to see why it was skipped. If using in-group dependencies, ensure all dependencies are included in your request.
Issue: Attribute failed with “required dependency missing value” error.Cause: A required dependency ran but didn’t produce a value (failed or empty result).Solution:
  • Check why the dependency failed - review its job logs
  • Consider making the dependency optional if the attribute can work without it
  • Fix the dependency’s configuration or source data
Issue: Cannot save dependency configuration due to circular dependencies.Cause: Attribute A depends on B, and B depends on A (directly or indirectly).Solution: Review your dependency graph and break the cycle. Restructure dependencies to flow in one direction.
Issue: Attributes running in unexpected order.Cause: Dependencies you didn’t expect are affecting execution order.Solution: Review all dependency configurations. Check for inherited dependencies from collections that may not be obvious.
Issue: Workflow takes much longer than expected.Causes:
  • Too many sequential dependencies forcing serial execution
  • Long dependency chains
  • Unnecessary required dependencies causing failures and retries
Solution:
  • Minimize dependency chains where possible
  • Use parallel execution by reducing dependencies
  • Consider making some dependencies optional

​
What’s Next?

Attribute Prompts

Customize agent prompts for each workflow stage

Collections & Groups

Organize products for workflow assignment

Bulk Operations

Run workflows across large product sets

Jobs & Monitoring

Monitor workflow execution and progress
Next: Learn about Bulk Operations to apply workflows at scale across your entire catalog.