forcedotcom/sf-skills

omnistudio-callable-apex-generate

Salesforce Industries Common Core (OmniStudio/Vlocity) Apex callable generation and review skill with 120-point scoring.

View source
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

omnistudio-callable-apex-generate: Callable Apex for Salesforce Industries Common Core

Specialist for Salesforce Industries Common Core callable Apex implementations. Produce secure, deterministic, and configurable Apex that cleanly integrates with OmniStudio and Industries extension points.

Scope

  • In scope: Creating System.Callable classes for Industries extension points; reviewing callable implementations for correctness and risks; migrating VlocityOpenInterface / VlocityOpenInterface2 to System.Callable; 120-point scoring and validation
  • Out of scope: Generic Apex classes without callable interface (use platform-apex-generate); building Integration Procedures (use omnistudio-integration-procedure-generate); authoring OmniScripts (use omnistudio-omniscript-generate); deploying Apex classes (use platform-metadata-deploy)

Core Responsibilities

  1. Callable Generation: Build System.Callable classes with safe action dispatch
  2. Callable Review: Audit existing callable implementations for correctness and risks
  3. Validation & Scoring: Evaluate against the 120-point rubric
  4. Industries Fit: Ensure compatibility with OmniStudio/Industries extension points

Workflow (4-Phase Pattern)

Phase 1: Requirements Gathering

Ask for:

  • Entry point (OmniScript, Integration Procedure, DataRaptor, or other Industries hook)
  • Action names (strings passed into call)
  • Input/output contract (required keys, types, and response shape)
  • Data access needs (objects/fields, CRUD/FLS (Create/Read/Update/Delete and Field-Level Security) rules)
  • Side effects (DML, callouts, async requirements)

Then:

  1. Scan for existing callable classes: Glob: **/*Callable*.cls
  2. Identify shared utilities or base classes used for Industries extensions
  3. Create a task list

Phase 2: Design & Contract Definition

Define the callable contract:

  • Action list (explicit, versioned strings)
  • Input schema (required keys + types)
  • Output schema (consistent response envelope)

Recommended response envelope:

json
{
  "success": true|false,
  "data": {...},
  "errors": [ { "code": "...", "message": "..." } ]
}

Action dispatch rules:

  • Use switch on action
  • Default case throws a typed exception
  • No dynamic method invocation or reflection

VlocityOpenInterface / VlocityOpenInterface2 contract mapping:

When designing for legacy Open Interface extensions (or dual Callable + Open Interface support), map the signature:

text
invokeMethod(String methodName, Map<String, Object> inputMap, Map<String, Object> outputMap, Map<String, Object> options)
ParameterRoleCallable equivalent
methodNameAction selector (same semantics as action)action in call(action, args)
inputMapPrimary input data (required keys, types)args.get('inputMap')
outputMapMutable map where results are written (out-by-reference)Return value; Callable returns envelope instead
optionsAdditional context (parent DataRaptor/OmniScript context, invocation metadata)args.get('options')

Design rules for Open Interface contracts:

  • Treat inputMap and options as the combined input schema
  • Define what keys must be written to outputMap per action (success and error cases)
  • Preserve methodName strings so they align with Callable action strings
  • Document whether options is required, optional, or unused for each action

Phase 3: Implementation Pattern

Vanilla System.Callable (flat args, no Open Interface coupling):

Read `assets/pattern_callable_vanilla.cls` before generating — use when callers pass flat args and no VlocityOpenInterface integration is required.

Callable skeleton (same inputs as VlocityOpenInterface):

Read `assets/pattern_callable_openinterface.cls` before generating — use inputMap and options keys in args when integrating with Open Interface or when callers pass that structure.

Input format: Callers pass args as { 'inputMap' => Map<String, Object>, 'options' => Map<String, Object> }. For backward compatibility with flat callers, if args lacks 'inputMap', treat args itself as inputMap and use an empty map for options.

Implementation rules:

  1. Keep call() thin; delegate to private methods or service classes
  2. Validate and coerce input types early (null-safe)
  3. Enforce CRUD/FLS (Create/Read/Update/Delete and Field-Level Security) and sharing (with sharing, Security.stripInaccessible())
  4. Bulkify when args include record collections
  5. Use WITH USER_MODE for SOQL when appropriate
  6. Namespace handling: System.Callable is a standard interface (no namespace prefix required); omnistudio.VlocityOpenInterface2 uses the managed omnistudio package namespace — always qualify it. If the callable class will be deployed into a namespaced managed package, ask the user for the namespace prefix and apply it to custom class names (e.g., myns__Industries_XxxCallable)

VlocityOpenInterface / VlocityOpenInterface2 implementation:

When implementing omnistudio.VlocityOpenInterface or omnistudio.VlocityOpenInterface2, use the signature:

apex
global Boolean invokeMethod(String methodName, Map<String, Object> inputMap,
                           Map<String, Object> outputMap, Map<String, Object> options)

Read `assets/pattern_openinterface.cls` before generating — complete VlocityOpenInterface2 skeleton with switch on dispatch and outputMap contract.

Open Interface implementation rules:

  • Write results into outputMap via putAll() or individual put() calls; do not return the envelope from invokeMethod
  • Return true for success, false for unsupported or failed actions
  • Use the same internal private methods as the Callable (same inputMap and options parameters); only the entry point differs
  • Populate outputMap with the same envelope shape (success, data, errors) for consistency

Both Callable and Open Interface accept the same inputs (inputMap, options) and delegate to identical private method signatures for shared logic.


Phase 4: Testing & Validation

Minimum tests:

  • Positive: Supported action executes successfully
  • Negative: Unsupported action throws expected exception
  • Contract: Missing/invalid inputs return error envelope
  • Bulk: Handles list inputs without hitting limits

Read `assets/pattern_test_class.cls` — complete test class skeleton (positive, negative, contract, bulk, and null-args cases) before generating tests.


Migration: VlocityOpenInterface to System.Callable

When modernizing Industries extensions, move VlocityOpenInterface or VlocityOpenInterface2 implementations to System.Callable and keep the action contract stable.

Guidance:

  • Preserve action names (methodName) as action strings in call()
  • Pass inputMap and options as keys in args: { 'inputMap' => inputMap, 'options' => options }
  • Return a consistent response envelope instead of mutating outMap
  • Keep call() thin; delegate to the same internal methods with (inputMap, options) signature
  • Add tests for each action and unsupported action

Read `assets/pattern_migration.cls` — annotated before/after migration example (VlocityOpenInterface2 → System.Callable) before starting migration work.


Best Practices (120-Point Scoring)

CategoryPointsKey Rules
Contract & Dispatch20Explicit action list; switch on; versioned action strings
Input Validation20Required keys validated; types coerced safely; null guards
Security20with sharing; CRUD/FLS checks; Security.stripInaccessible()
Error Handling15Typed exceptions; consistent error envelope; no empty catch
Bulkification & Limits20No SOQL/DML in loops; supports list inputs
Testing15Positive/negative/contract/bulk tests
Documentation10ApexDoc (/** ... */ block comments — Salesforce Apex documentation standard) for class and action methods

Thresholds: [PASS] 90+ (Ready) | [REVIEW] 70-89 (Review) | [BLOCK] <70 (Block)


Guardrails (Mandatory)

Stop and ask the user if any of these would be introduced:

  • Dynamic method execution based on user input (no reflection)
  • SOQL/DML inside loops
  • without sharing on callable classes
  • Silent failures (empty catch, swallowed exceptions)
  • Inconsistent response shapes across actions

Gotchas

IssueResolution
Caller passes flat args but code expects inputMap keyGuard defensively: if args lacks 'inputMap' key, treat args itself as the input map
call() receives null for argsAlways null-check args before accessing keys; initialize to empty map if null
Test class uses (Map<String, Object>) svc.call(...) but call returns a wrong typeEnsure every action returns the same envelope type (Map<String, Object>) — mixed return types break callers
VlocityOpenInterface2 migration breaks callers that read outputMap by referenceAfter migrating to Callable, callers must read the return value instead of reading outputMap — update all callers
IndustriesCallableException class missing in projectThis custom exception must be deployed alongside the callable class — include it in every deployment package
Org has both legacy Open Interface and new Callable wired to same actionOnly one entry point should be active at a time; disable the old interface after confirming the callable works

Common Anti-Patterns

  • call() contains business logic instead of delegating
  • Action names are unversioned or not documented
  • Input maps assumed to have keys without checks
  • Mixed response types (sometimes Map, sometimes String)
  • No tests for unsupported actions

Cross-Skill Integration

SkillWhen to UseExample
platform-apex-generateGeneral Apex work beyond callable implementations"Create trigger for Account"
platform-custom-object-generate / platform-custom-field-generateVerify object/field availability before coding"Describe Product2 fields"
platform-metadata-deployValidate/deploy callable classes"Deploy to sandbox"

Reference Skill

Use the core Apex standards, testing patterns, and guardrails in:


Bundled Examples

Output Expectations

Deliverables produced by this skill:

  • <ClassName>.cls — Callable class implementing System.Callable with switch on action dispatch
  • <ClassName>Test.cls — Test class with positive, negative, contract, and bulk test methods
  • IndustriesCallableException.cls — Custom exception class (if not already present in the project)

Notes

  • Prefer deterministic, side-effect-aware callable actions
  • Keep action contracts stable; introduce new actions for breaking changes
  • Avoid long-running work in synchronous callables; use async when needed

Reference File Index

FileWhen to read
assets/pattern_callable_vanilla.clsPhase 3 — vanilla System.Callable skeleton (flat args, no Open Interface coupling)
assets/pattern_callable_openinterface.clsPhase 3 — System.Callable skeleton with inputMap/options args (Open Interface-compatible)
assets/pattern_openinterface.clsPhase 3 — VlocityOpenInterface2 skeleton with switch on dispatch and outputMap contract
assets/pattern_test_class.clsPhase 4 — test class skeleton (positive, negative, contract, bulk, and null-args cases)
assets/pattern_migration.clsMigration — annotated before/after migration pattern (VlocityOpenInterface2 → System.Callable)
examples/Test_QuoteByProductCallable/Industries_QuoteByProductCallable.clsPhase 3 — complete callable implementation with WITH USER_MODE SOQL and error envelope
examples/Test_QuoteByProductCallable/Industries_QuoteByProductCallableTest.clsPhase 4 — full test class covering positive, contract, and unsupported-action cases
examples/Test_QuoteByProductCallable/IndustriesCallableException.clsPhase 3 — custom exception pattern for unsupported actions
examples/Test_QuoteByProductCallable/TRANSCRIPT.mdReference — reasoning transcript for the Quote-by-Product callable example
examples/Test_VlocityOpenInterfaceConversion/MyCustomCallable.clsPhase 3 — migration pattern from legacy VlocityOpenInterface
examples/Test_VlocityOpenInterfaceConversion/MyCustomCallableTest.clsPhase 4 — test class for VlocityOpenInterface migration example
examples/Test_VlocityOpenInterfaceConversion/IndustriesCallableException.clsPhase 3 — custom exception class deployed alongside VlocityOpenInterface conversion
examples/Test_VlocityOpenInterfaceConversion/MyCustomClass.clsPhase 3 — the original legacy VlocityOpenInterface class before migration
examples/Test_VlocityOpenInterfaceConversion/TRANSCRIPT.mdReference — reasoning transcript for VlocityOpenInterface conversion
examples/Test_VlocityOpenInterface2Conversion/MyCustomCallable.clsPhase 3 — migration pattern from VlocityOpenInterface2
examples/Test_VlocityOpenInterface2Conversion/MyCustomCallableTest.clsPhase 4 — test class for VlocityOpenInterface2 migration example
examples/Test_VlocityOpenInterface2Conversion/IndustriesCallableException.clsPhase 3 — custom exception class deployed alongside VlocityOpenInterface2 conversion
examples/Test_VlocityOpenInterface2Conversion/MyCustomRemoteClass.clsPhase 3 — remote class used by the VlocityOpenInterface2 migration example
examples/Test_VlocityOpenInterface2Conversion/TRANSCRIPT.mdReference — reasoning transcript for VlocityOpenInterface2 conversion

Pre-Delivery Checklist

  • [ ] call() null-checks args before accessing keys
  • [ ] IndustriesCallableException class included in deployment package
  • [ ] Namespace qualified for omnistudio.VlocityOpenInterface2 (if applicable)
  • [ ] outputMap keys documented per action (success and error cases)
  • [ ] Migrated callers read return value instead of outputMap by reference
from this repository

More skills

All skills
forcedotcom
Community

design-systems-slds-apply

Apply SLDS-compliant UI using the correct blueprints, styling hooks, utility classes, and icons. Use when building any UI that needs SLDS, choosing between Lightning Base Components and SLDS Blueprints, applying styling hooks for theming, using utility classes for layout and spacing, or selecting icons. Triggers include \"build a modal\", \"create a form\", \"data table\", \"SLDS styling\", \"style with hooks\", \"add an icon\".

installs
5
GitHub stars
948
Updated
28 ago
forcedotcom
Community

design-systems-slds-validate

Audit Lightning Web Components for SLDS design-system compliance and produce a scored quality report. Runs the SLDS linter and analyzes CSS for theming hook usage and pairing, scoring SLDS findings across categories into an overall grade. Use when asked to \"score my component's SLDS\", \"SLDS scorecard\", \"SLDS quality report\", \"audit SLDS compliance\", \"how good is my SLDS\", \"check SLDS quality\", \"rate my SLDS styling\", \"evaluate my component's SLDS\", \"is this component's SLDS ready to ship?\", \"look at my LWC for SLDS issues\", \"audit SLDS before I submit\", \"review my component's SLDS before code review\", or any time a user wants an SLDS quality assessment or SLDS production-readiness check on an LWC. Not for fixing violations (use design-systems-slds2-migrate), building new components (use design-systems-slds-apply), or accessibility/WCAG/ARIA audits (use experience-accessibility-validate).

installs
5
GitHub stars
948
Updated
28 ago
forcedotcom
Community

design-systems-slds2-migrate

Migrate Lightning Web Components from SLDS 1 to SLDS 2 by running the SLDS linter and fixing violations. Use this skill whenever users mention SLDS 2, SLDS uplift, linter violations, LWC token migration, class overrides, hardcoded CSS values that need SLDS hook replacement, or styling hook selection. Covers all styling hook categories — color, spacing, sizing, typography, borders, radius, and shadows. Also use when users mention no-hardcoded-values, no-slds-class-overrides, lwc-to-slds-hooks, no-deprecated-tokens-slds1, or ask about SLDS component migration — even if they don't explicitly say \"uplift\" or \"migration\".

installs
5
GitHub stars
948
Updated
28 ago
forcedotcom
Community

agentforce-architecture-analyze

Declared architecture snapshot for one Agentforce agent: planner, topics, actions, flows, Apex, prompt templates, and NGA plugins. Renders a human-readable architecture document and Mermaid invocation graph from design-time metadata (not runtime audit rows). TRIGGER when user asks to describe, diagram, inventory, audit, document, or diff (e.g. v3 vs v5) the architecture / action tree / topic structure / tool inventory of a specific agent by agent API name in a specific org. DO NOT TRIGGER for runtime session traces, conversation transcripts, generation timings, or gateway audit chains — this skill reads design-time metadata only (use agentforce-d360-analyze for session traces).

installs
4
GitHub stars
948
Updated
28 ago