Per-Send Governor Limit Consumption
Numbers below are per outbound send throughChertSendIMessage,
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
CallingChertSendIMessage 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:HttpCalloutMock. No test makes
a real callout; runs are deterministic and offline.
A passing run looks like this:
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.MobilePhoneandLead.Phoneis 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__cis 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. ThechertConversation 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 ownTenant_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 anidempotencyKey. 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 returnsok: 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 MessagingModified custom metadata record: Chert_Tenant.DefaultActivated Lightning page: Lead_Record_Page_ChertActivated Lightning page: Contact_Record_Page_ChertActivated Lightning page: Account_Record_Page_ChertAssigned permission set: Chert Messaging User
Chert_ to audit every
package-related change.
See Also
- SECURITY for the trust boundary and signature format.
- ARCHITECTURE for synchronous-versus-asynchronous behavior.
- Apex Developer Guide — Execution Governors and Limits
- General Shield Platform Encryption Considerations

