Architecture

Salesforce-native, cloud-hosted, model-agnostic

WeaveOps is composed of three layers: a Salesforce-side orchestration and runtime layer, an Azure-hosted AI service layer, and the AI model provider. Each layer has distinct responsibilities and security boundaries.

System overview

Layer 1 — Salesforce Org
LWC
aiAdminConsole
LWC
aiUseCaseRunner
LWC
aiCallCoach / aiConversation
Apex Services
AIUseCaseServiceAITenantServiceAIAdminControllerAIBatchProcessorAIConversationController
HTTPS · Named Credential · X-API-Key header
Layer 2 — Azure App Service (WeaveOps AI Service)
POST /execute
Generic AI workflow execution
POST /converse
Multi-turn conversation
POST /coach
Live call coaching
POST /pipeline
Pipeline digest
PUT /instructions
Instruction file management
GET /admin/*
Admin and analytics endpoints
Azure Blob Storage
Instruction files · Interaction logs · Tenant registry
Flask-Limiter
Per-tenant rate limiting · 500/hr default
HTTPS · Anthropic API key (Azure env var)
Layer 3 — AI Model Provider
Anthropic Claude
claude-sonnet-4-6 (default) · configurable per use case
Model selection and prompt shaping handled by the service layer. Salesforce never communicates directly with the model provider.

Request flow — single use case execution

What happens when a Salesforce user triggers a WeaveOps use case on a record page.

1
User triggers the component
The user opens a record page or clicks a WeaveOps component. The LWC calls an @AuraEnabled Apex method.
2
Salesforce assembles context
AIUseCaseService loads the use case configuration from Salesforce metadata, executes configured data sources (SOQL queries, field reads, related lists), and assembles a structured payload. CRUD/FLS is enforced on every field read.
3
Callout to WeaveOps service
The Apex service sends the assembled payload to the Azure Flask endpoint via a Salesforce Named Credential. The API key is injected automatically by the External Credential — Apex never sees it.
4
Service builds and sends the prompt
The Flask service loads the instruction file for the use case, builds the system prompt (including a non-overridable tenant identity preamble), assembles the user prompt from the payload data, validates input lengths, and calls the Anthropic API.
5
AI response is parsed
The model returns a structured JSON response. The service validates, logs, and returns it to Salesforce. Interaction metadata (tokens, duration, model version) is logged to Azure Blob under the tenant namespace.
6
Response is applied in Salesforce
Back in Salesforce, AIUseCaseService applies the configured response mappings: updating fields, creating child records, setting Flow variables, or returning the result to the LWC for user confirmation. Field-level update permissions are checked before each write.

Multi-tenant service design

The WeaveOps AI service is designed to serve multiple Salesforce orgs from a single deployment. Each org is identified by a tenant ID (the Salesforce org ID) and authenticated with an independently issued API key.

Isolated storage
Each tenant's instruction files and interaction logs are stored under their org ID prefix in Azure Blob. Cross-tenant data access is not possible through the API.
Tenant-namespaced system prompts
Every AI call includes a non-overridable preamble in the system prompt identifying the tenant. This ensures cross-tenant prompt injection attempts are detectable in logs.
Independent rate limiting
Rate limits are tracked per tenant ID. One tenant's high request volume does not affect another tenant's allocation.
Admin isolation
Admin endpoints require a separate admin key that is never issued to tenants. Tenant keys cannot access the admin API.
Tenant registration (admin only) 
POST /admin/tenant/register
X-Admin-Key: ••••••••••••

{
  "tenantId":  "00D000000000001",
  "apiKey":    "wops-tenant-key",
  "label":     "Acme Corp - Production"
}

→ 201 Created
{
  "tenantId": "00D000000000001",
  "registered": true
}
Tenant API keys are stored hashed in Azure Blob Storage. The plain-text key is only returned at registration time.

Operational details

Retry logic

LLM calls are retried up to 3 times on rate limit errors and network timeouts, with exponential backoff (5s, 10s, 20s). Batch record processing retries failed records up to 3 times before skipping with an error log entry.

Batch processing

Large-scale record processing uses Salesforce Queueable Apex with a chain pattern: one record per queue execution, self-re-enqueuing until all records are processed. Progress is tracked in real time on the Batch Run record.

JSON response repair

The AI service includes a JSON repair pipeline that handles truncated or bracket-mismatched model output. It escalates max tokens and retries when the model's response is structurally incomplete.

Input length limits

All user-supplied text fields are validated to a 50,000 character maximum before reaching the AI model. List inputs (conversation history) are capped at 200 items. Oversized inputs return a 400 error immediately.

Callout limits

WeaveOps respects Salesforce's synchronous callout limits. Document analysis and batch processing use asynchronous Queueable Apex to avoid blocking user transactions. Timeout is configurable per endpoint.

Health endpoint

The WeaveOps service exposes a /health endpoint returning service status and configuration flags (Anthropic connected, Blob connected). No authentication required — used for monitoring and support diagnostics.