
sf-industry-commoncore-callable-apex
Salesforce Industries Common Core (OmniStudio/Vlocity) Apex callable generation and review with 120-point scoring. TRIGGER when: user creates or reviews System.Callable classes, migrates VlocityOpenInterface / VlocityOpenInterface2, or builds Industries callable extensions used by OmniStudio, Integration Procedures, or DataRaptors. DO NOT TRIGGER when: generic Apex classes/triggers (use sf-apex), building Integration Procedures (use sf-industry-commoncore-integration-procedure), authoring OmniScripts (use sf-industry-commoncore-omniscript), configuring Data Mappers (use sf-industry-commoncore-datamapper), or analyzing namespace/dependency issues (use sf-industry-commoncore-omnistudio-analyze).
- Installs
- 951
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/jaganpro/sf-skills --skill sf-industry-commoncore-callable-apex- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads sf-industry-commoncore-callable-apex automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
sf-industry-commoncore-callable-apex: 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.
Core Responsibilities
- Callable Generation: Build
System.Callableclasses with safe action dispatch - Callable Review: Audit existing callable implementations for correctness and risks
- Validation & Scoring: Evaluate against the 120-point rubric
- 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 rules)
- Side effects (DML, callouts, async requirements)
Then:
- Scan for existing callable classes:
Glob: **/*Callable*.cls - Identify shared utilities or base classes used for Industries extensions
- 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:
{
"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:
invokeMethod(String methodName, Map<String, Object> inputMap, Map<String, Object> outputMap, Map<String, Object> options)
| Parameter | Role | Callable equivalent |
|---|---|---|
methodName | Action selector (same semantics as action) | action in call(action, args) |
inputMap | Primary input data (required keys, types) | args.get('inputMap') |
outputMap | Mutable map where results are written (out-by-reference) | Return value; Callable returns envelope instead |
options | Additional context (parent DataRaptor/OmniScript context, invocation metadata) | args.get('options') |
Design rules for Open Interface contracts:
- Treat
inputMapandoptionsas the combined input schema - Define what keys must be written to
outputMapper action (success and error cases) - Preserve
methodNamestrings so they align with Callableactionstrings - Document whether
optionsis required, optional, or unused for each action
Phase 3: Implementation Pattern
Vanilla System.Callable (flat args, no Open Interface coupling):
public with sharing class Industries_OrderCallable implements System.Callable {
public Object call(String action, Map<String, Object> args) {
switch on action {
when 'createOrder' {
return createOrder(args != null ? args : new Map<String, Object>());
}
when else {
throw new IndustriesCallableException('Unsupported action: ' + action);
}
}
}
private Map<String, Object> createOrder(Map<String, Object> args) {
// Validate input (e.g. args.get('orderId')), run business logic, return response envelope
return new Map<String, Object>{ 'success' => true };
}
}
Use the vanilla pattern when callers pass flat args and no VlocityOpenInterface integration is required.
Callable skeleton (same inputs as VlocityOpenInterface):
Use inputMap and options keys in args when integrating with Open Interface or when callers pass that structure:
public with sharing class Industries_OrderCallable implements System.Callable {
public Object call(String action, Map<String, Object> args) {
Map<String, Object> inputMap = (args != null && args.containsKey('inputMap'))
? (Map<String, Object>) args.get('inputMap') : (args != null ? args : new Map<String, Object>());
Map<String, Object> options = (args != null && args.containsKey('options'))
? (Map<String, Object>) args.get('options') : new Map<String, Object>();
if (inputMap == null) { inputMap = new Map<String, Object>(); }
if (options == null) { options = new Map<String, Object>(); }
switch on action {
when 'createOrder' {
return createOrder(inputMap, options);
}
when else {
throw new IndustriesCallableException('Unsupported action: ' + action);
}
}
}
private Map<String, Object> createOrder(Map<String, Object> inputMap, Map<String, Object> options) {
// Validate input, run business logic, return response envelope
return new Map<String, Object>{ 'success' => true };
}
}
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:
- Keep
call()thin; delegate to private methods or service classes - Validate and coerce input types early (null-safe)
- Enforce CRUD/FLS and sharing (
with sharing,Security.stripInaccessible()) - Bulkify when args include record collections
- Use
WITH USER_MODEfor SOQL when appropriate
VlocityOpenInterface / VlocityOpenInterface2 implementation:
When implementing omnistudio.VlocityOpenInterface or omnistudio.VlocityOpenInterface2, use the signature:
global Boolean invokeMethod(String methodName, Map<String, Object> inputMap,
Map<String, Object> outputMap, Map<String, Object> options)
Open Interface skeleton:
global with sharing class Industries_OrderOpenInterface implements omnistudio.VlocityOpenInterface2 {
global Boolean invokeMethod(String methodName, Map<String, Object> inputMap,
Map<String, Object> outputMap, Map<String, Object> options) {
switch on methodName {
when 'createOrder' {
Map<String, Object> result = createOrder(inputMap, options);
outputMap.putAll(result);
return true;
}
when else {
outputMap.put('success', false);
outputMap.put('errors', new List<Map<String, Object>>{
new Map<String, Object>{ 'code' => 'UNSUPPORTED_ACTION', 'message' => 'Unsupported action: ' + methodName }
});
return false;
}
}
}
private Map<String, Object> createOrder(Map<String, Object> inputMap, Map<String, Object> options) {
// Validate input, run business logic, return response envelope
return new Map<String, Object>{ 'success' => true, 'data' => new Map<String, Object>() };
}
}
Open Interface implementation rules:
- Write results into
outputMapviaputAll()or individualput()calls; do not return the envelope frominvokeMethod - Return
truefor success,falsefor unsupported or failed actions - Use the same internal private methods as the Callable (same
inputMapandoptionsparameters); only the entry point differs - Populate
outputMapwith 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
Example test class:
@IsTest
private class Industries_OrderCallableTest {
@IsTest
static void testCreateOrder() {
System.Callable svc = new Industries_OrderCallable();
Map<String, Object> args = new Map<String, Object>{
'inputMap' => new Map<String, Object>{ 'orderId' => '001000000000001' },
'options' => new Map<String, Object>()
};
Map<String, Object> result =
(Map<String, Object>) svc.call('createOrder', args);
Assert.isTrue((Boolean) result.get('success'));
}
@IsTest
static void testUnsupportedAction() {
try {
System.Callable svc = new Industries_OrderCallable();
svc.call('unknownAction', new Map<String, Object>());
Assert.fail('Expected IndustriesCallableException');
} catch (IndustriesCallableException e) {
Assert.isTrue(e.getMessage().contains('Unsupported action'));
}
}
}
Migration: VlocityOpenInterface to System.Callable
When modernizing Industries extensions, move VlocityOpenInterface or
VlocityOpenInterface2 implementations to System.Callable and keep the
action contract stable. Use the Salesforce guidance as the source of truth.
Salesforce Help
Guidance:
- Preserve action names (
methodName) asactionstrings incall() - Pass
inputMapandoptionsas keys inargs:{ '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
Example migration (pattern):
// BEFORE: VlocityOpenInterface2
global class OrderOpenInterface implements omnistudio.VlocityOpenInterface2 {
global Boolean invokeMethod(String methodName, Map<String, Object> input,
Map<String, Object> output,
Map<String, Object> options) {
if (methodName == 'createOrder') {
output.putAll(createOrder(input, options));
return true;
}
return false;
}
}
// AFTER: System.Callable (same inputs: inputMap, options)
public with sharing class OrderCallable implements System.Callable {
public Object call(String action, Map<String, Object> args) {
Map<String, Object> inputMap = args != null ? (Map<String, Object>) args.get('inputMap') : new Map<String, Object>();
Map<String, Object> options = args != null ? (Map<String, Object>) args.get('options') : new Map<String, Object>();
if (inputMap == null) { inputMap = new Map<String, Object>(); }
if (options == null) { options = new Map<String, Object>(); }
switch on action {
when 'createOrder' {
return createOrder(inputMap, options);
}
when else {
throw new IndustriesCallableException('Unsupported action: ' + action);
}
}
}
}
Best Practices (120-Point Scoring)
| Category | Points | Key Rules |
|---|---|---|
| Contract & Dispatch | 20 | Explicit action list; switch on; versioned action strings |
| Input Validation | 20 | Required keys validated; types coerced safely; null guards |
| Security | 20 | with sharing; CRUD/FLS checks; Security.stripInaccessible() |
| Error Handling | 15 | Typed exceptions; consistent error envelope; no empty catch |
| Bulkification & Limits | 20 | No SOQL/DML in loops; supports list inputs |
| Testing | 15 | Positive/negative/contract/bulk tests |
| Documentation | 10 | ApexDoc for class and action methods |
Thresholds: ✅ 90+ (Ready) | ⚠️ 70-89 (Review) | ❌ <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 sharingon callable classes- Silent failures (empty catch, swallowed exceptions)
- Inconsistent response shapes across actions
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
| Skill | When to Use | Example |
|---|---|---|
| sf-apex | General Apex work beyond callable implementations | "Create trigger for Account" |
| sf-metadata | Verify object/field availability before coding | "Describe Product2" |
| sf-deploy | Validate/deploy callable classes | "Deploy to sandbox" |
Reference Skill
Use the core Apex standards, testing patterns, and guardrails in:
- skills/sf-apex/SKILL.md
Bundled Examples
- examples/Test_QuoteByProductCallable/ — read-only query example with
WITH USER_MODE - examples/Test_VlocityOpenInterfaceConversion/ — migration from legacy
VlocityOpenInterface - examples/Test_VlocityOpenInterface2Conversion/ — migration from
VlocityOpenInterface2
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
FAQ
What does the sf-industry-commoncore-callable-apex skill do?
Salesforce Industries Common Core (OmniStudio/Vlocity) Apex callable generation and review with 120-point scoring. TRIGGER when: user creates or reviews System.Callable classes, migrates VlocityOpenInterface / VlocityOpenInterface2, or builds Industries callable extensions used by OmniStudio, Integration Procedures, or DataRaptors. DO NOT TRIGGER when: generic Apex classes/triggers (use sf-apex), building Integration Procedures (use sf-industry-commoncore-integration-procedure), authoring OmniScripts (use sf-industry-commoncore-omniscript), configuring Data Mappers (use sf-industry-commoncore-datamapper), or analyzing namespace/dependency issues (use sf-industry-commoncore-omnistudio-analyze).
How do I install sf-industry-commoncore-callable-apex?
Run npx skills add https://github.com/jaganpro/sf-skills --skill sf-industry-commoncore-callable-apex in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/sf-industry-commoncore-callable-apex/ (personal) or .claude/skills/sf-industry-commoncore-callable-apex/ (project).
Which AI agents can use sf-industry-commoncore-callable-apex?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is sf-industry-commoncore-callable-apex safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains sf-industry-commoncore-callable-apex?
It is published by jaganpro in jaganpro/sf-skills. It has 951 recorded installs.
More from jaganpro/sf-skills
sf-apex
jaganpro/sf-skills
Generates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
sf-lwc
jaganpro/sf-skills
Lightning Web Components with PICKLES methodology and 165-point scoring. TRIGGER when: user creates/edits LWC components, touches lwc//.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use sf-apex), Aura components, or Visualforce.
sf-flow
jaganpro/sf-skills
Creates and validates Salesforce Flows with 110-point scoring. TRIGGER when: user builds or edits record-triggered, screen, autolaunched, or scheduled flows, or touches .flow-meta.xml files. DO NOT TRIGGER when: Apex automation (use sf-apex), process builder migration questions only, or non-Flow declarative config (use sf-metadata).
sf-metadata
jaganpro/sf-skills
Salesforce metadata generation and querying with 120-point scoring. TRIGGER when: user creates custom objects, fields, validation rules, or touches .object-meta.xml, .field-meta.xml, .profile-meta.xml files. DO NOT TRIGGER when: permission set analysis (use sf-permissions), deploying metadata (use sf-deploy), or Flow XML (use sf-flow).
sf-soql
jaganpro/sf-skills
SOQL query generation, optimization, and analysis with 100-point scoring. TRIGGER when: user writes, optimizes, or debugs SOQL/SOSL queries, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER when: bulk data operations (use sf-data), Apex DML logic (use sf-apex), or report/dashboard queries.
sf-debug
jaganpro/sf-skills
Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use sf-testing), fixing Apex code (use sf-apex), or Agentforce session tracing (use sf-ai-agentforce-observability).
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.