Skip to main content
Capacity planning, edition compatibility, and platform-feature behavior. Read before piloting in production.

Per-Send Governor Limit Consumption

Numbers below are per outbound send through ChertSendIMessage, measured against the synchronous Apex transaction limits. The package does not consume future invocations, queueable invocations, or scheduled Apex slots during a synchronous send.

Bulk Sends from Triggers

Calling ChertSendIMessage from a trigger on more than one record at a time chunks the work. The first 80 sends run in the trigger transaction; overflow is enqueued through System.enqueueJob to a Queueable that honours the same dedup and signature contract. Queueable chaining respects the platform’s 50-job synchronous depth limit. For initial-load scenarios above 1,000 records, prefer scheduling sends through the ChertSendIMessage invocable inside a Flow with a Wait element rather than firing all-at-once from a trigger.

Daily Send Capacity

The platform imposes no daily Apex callout cap. Daily send volume is bounded by Chert-side per-line capacity. Each Chert phone line has a fixed daily first-touch budget. When all lines are saturated, ChertSendIMessage returns a duplicate=false, ok=false response with an explanatory error code; the Flow can route the failure for re-attempt the following day. Capacity provisioning is sized to your expected volume during tenant onboarding.

Apex Test Coverage

Shipped coverage is ≥ 85% line coverage per class. Reproduce locally:
Every HTTP callout path is covered by HttpCalloutMock. No test makes a real callout; runs are deterministic and offline. A passing run looks like this:
The deploy gate (sf project deploy start --test-level RunLocalTests) fails if Org Wide Coverage drops below the platform’s 75% bar. Shipped coverage holds at 91% so a regression has room to surface before blocking deploys.

Edition Support

User Interface

Platform Feature Compatibility

Person Account

Supported. chertConversation and ChertSendIMessage detect Account.IsPersonAccount and route the contact resolution through the Person Account’s contact half. No additional configuration required.

Shield Platform Encryption

The package is compatible with Shield Platform Encryption with the following considerations:
  • Probabilistic encryption on Contact.MobilePhone and Lead.Phone is fully supported. The package reads and writes through standard formula-free field references.
  • Deterministic encryption is required if your administrators want to use phone-number-based duplicate matching across the standard CRM duplicate rules.
  • The custom field Chert_Message__c.Text__c is a Long Text Area and supports Shield encryption. Encrypt it at the field level through Setup → Encryption Policy if your data-classification policy requires it.

Multi-Currency

Compatible. The package defines no currency fields and performs no currency arithmetic.

Translation Workbench

Field labels, picklist values, and the Permission Set label can be translated through Translation Workbench. The chertConversation LWC’s hard-coded user-facing strings are not yet externalized; flag during v2 planning if multi-language support is needed.

Government Cloud and Hyperforce

The package’s Apex and metadata are Hyperforce-compatible. Validation against Government Cloud Plus has not been performed; do not deploy to GovCloud Plus Orgs without consulting Chert.

Sandbox versus Production

The package metadata is identical across sandboxes and production. The Custom Metadata record values differ: each environment must be configured with its own Tenant_Slug__c, Signing_Secret__c, and Ingest_Token__c. Do not copy production secrets into sandboxes; ask Chert for a sandbox-specific tenant.

Idempotency

Every send accepts an idempotencyKey. Within a 6-hour rolling window, re-invoking with the same key is a no-op and returns duplicate: true. Treat duplicate: true as success in Flow logic. If your Flow does not supply idempotencyKey, the package generates one as <recordId>:<sha256(message-body)>, which is stable across retries of the same logical action.

Retry Semantics

Outbound HTTP failures (network timeout, 5xx) are not auto-retried by the package. The invocable returns ok: false with an error code; the Flow should branch on the result and either retry or surface the error to the user. This is intentional — silent retries are difficult to reason about in declarative tooling, so the contract surfaces the choice to the Flow author.

Setup Audit Trail

The package writes the following entries to Setup Audit Trail on install and configuration changes:
  • Installed package: Chert Messaging
  • Modified custom metadata record: Chert_Tenant.Default
  • Activated Lightning page: Lead_Record_Page_Chert
  • Activated Lightning page: Contact_Record_Page_Chert
  • Activated Lightning page: Account_Record_Page_Chert
  • Assigned permission set: Chert Messaging User
Compliance teams can grep the trail for Chert_ to audit every package-related change.

See Also