/*
 * Copyright 2026, Jaime Terrats.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
import { workflow } from '../workflow-generator.js';
export function generateIndustriesWorkflows(version) {
    return {
        'industries-platform-setup.md': workflow(version, 'Industries Platform Setup', `
## 1. Gather Requirements

Ask:
- **Industry vertical:** Which Industries Cloud vertical is this project targeting (Communications, Media, Energy, Health, Financial Services)?
- **Package version:** What is the installed Industries managed package version? (Check \`sfdx force:package:installed:list\`)
- **OmniStudio dependency:** Is OmniStudio (standard or managed) already installed? Which version?
- **Data model extensions:** Are there custom objects beyond the Industries standard model?
- **Integration Procedures:** Are there existing DataRaptors or Integration Procedures to reuse?
- **Orchestration:** Does the project use Industries Order Management or custom orchestration plans?

Check \`force-app/main/default/objects/\` for existing \`vlocity_cmt__\` or \`omnistudio__\` objects before extending.

## 2. Verify Platform Dependencies

### Package Inventory
1. Run \`sf package installed list --target-org <alias>\` to confirm Industries packages.
2. Verify OmniStudio version compatibility with the Industries package.
3. Check for deprecated Vlocity namespace (\`vlocity_cmt__\`) vs new Industries namespace (\`omnistudio__\`).
4. Document the exact package versions for reproducible deployments.

### Namespace Strategy
- **Vlocity managed (\`vlocity_cmt__\`):** Legacy installations prior to Industries Cloud unification.
- **OmniStudio standard (\`omnistudio__\`):** Newer installations using the standard namespace.
- **Industries common:** Objects like \`ActionPlanTemplate\`, \`BusinessMilestone\` use no namespace.
- Determine which namespace applies and document in the project's CLAUDE.md.

## 3. Configure Industries Common Objects

### Action Plans
- \`ActionPlanTemplate\`: Define step-by-step processes for onboarding, service fulfillment, compliance.
- \`ActionPlanTemplateItem\`: Individual steps within a template, with sequence and dependencies.
- Link templates to record types or process types for automatic plan generation.

### Business Rules Engine
- \`BusinessRuleGroup\`: Logical grouping of decision rules.
- \`DecisionTable\`: Tabular rule definitions for pricing, eligibility, or routing decisions.
- Use Decision Tables over Apex logic for business rules that change frequently.

### Document Generation
- Industries Document Generation for contracts, proposals, and compliance documents.
- Configure templates using Industries-native document builder or external template engines.

## 4. Set Up OmniStudio Components

### OmniScripts
- Guided user experiences for complex processes (onboarding, ordering, claims).
- Use DataRaptors for object reads/writes within OmniScript steps.
- Call Integration Procedures for complex multi-object operations.
- Version OmniScripts: keep active version stable, develop on new versions.

### DataRaptors
- **Extract:** Read Salesforce data into OmniScript-consumable JSON.
- **Transform:** Reshape data between systems without DML.
- **Load:** Write data back to Salesforce objects.
- Prefer DataRaptors over Apex for standard CRUD within OmniStudio flows.

### FlexCards
- Contextual UI components embedded in record pages or Experience Cloud.
- Data source: DataRaptors, SOSL, Apex Remote, or Integration Procedures.
- Keep FlexCards lightweight — delegate complex logic to backing Integration Procedures.

## 5. Deploy and Validate

\`\`\`bash
sf project deploy start \\
  --source-dir force-app/main/default/objects \\
  --source-dir force-app/main/default/omniDataTransforms \\
  --source-dir force-app/main/default/omniIntegrationProcedures \\
  --source-dir force-app/main/default/omniScripts \\
  --target-org <alias>
\`\`\`

Verify in the target org:
- OmniStudio components are active and versioned correctly
- DataRaptors execute without field-level security errors
- Action Plan Templates generate plans on record creation
- FlexCards render data correctly on target record pages
`),
        'industries-order-management.md': workflow(version, 'Industries Order Management', `
## 1. Gather Requirements

Ask:
- **Order types:** What types of orders does the business process? (new service, change, disconnect, move)
- **Decomposition rules:** How should commercial orders split into fulfillment orders? (by service type, by system, by geography)
- **Fulfillment domains:** Which downstream systems handle fulfillment steps? (provisioning, billing, inventory, field service)
- **SLA requirements:** Are there time-based SLAs for end-to-end order completion or individual steps?
- **Fallout management:** What is the escalation path when fulfillment steps fail?

## 2. Configure Order Decomposition

### Decomposition Relationships
- Define rules in \`vlocity_cmt__DecompositionRelationship__c\` (or Industries-standard equivalent).
- Map commercial order items to fulfillment domains based on product specification type.
- Test decomposition with representative orders covering all product types and action codes.

### Action Codes
- \`Add\`: New service activation.
- \`Modify\`: Change to existing service (upgrade, downgrade, attribute change).
- \`Delete\`: Service disconnect or cancellation.
- \`NoChange\`: Line item included for context but requires no fulfillment action.

## 3. Configure Orchestration Plans

### Plan Design
1. Create orchestration plans per fulfillment domain.
2. Define steps with execution order (sequential or parallel groups).
3. Assign step types: Auto (API callout), Manual (human task), Event (Platform Event), Sub-orchestration.
4. Set completion criteria, timeout values, and retry policies per step.

### Integration Points
- Use Named Credentials for all external system authentication.
- Implement Integration Procedures for complex multi-step fulfillment logic.
- Publish Platform Events for async downstream system notifications.
- Subscribe to response events for step completion acknowledgment.

## 4. Configure Fallout Handling

1. Define retry policies: max attempts, exponential backoff intervals.
2. Configure escalation queues for manual intervention.
3. Implement compensating actions (rollback) for partial failures.
4. Create monitoring dashboards for order pipeline health.

## 5. Deploy and Validate

\`\`\`bash
sf project deploy start \\
  --source-dir force-app/main/default/objects/OrderItem \\
  --source-dir force-app/main/default/objects/vlocity_cmt__OrchestrationPlan__c \\
  --source-dir force-app/main/default/objects/vlocity_cmt__OrchestrationItem__c \\
  --target-org <alias>
\`\`\`

Verify:
- Test orders decompose into expected fulfillment orders
- Orchestration plans execute steps in correct sequence
- Fallout handling triggers on simulated failures
- Order lifecycle states align with TMF622/TMF641 standards
`),
    };
}
//# sourceMappingURL=industries.js.map