RAIN OS is a Salesforce-native foundation for agents, communications, phone and voice, outreach, recommendations, and operational AI. It can be installed and used independently. RAIN Intelligence is an optional add-on that extends reasoning, retrieval, tools, artifacts, and hosted workspaces.

Choose a learning path

Use one operating pattern

1. Define the business outcome, audience, authorized data, allowed actions, and human owner.
2. Configure the smallest agent and channel that can accomplish the job.
3. Add only necessary context, knowledge, variables, and tools.
4. Test normal, incomplete, restricted, and failure cases.
5. Publish a traceable version and release it to a controlled audience.
6. Monitor Salesforce records and provider results separately.
7. Expand only after completion and recovery behavior are reliable.

Open the Setup Wizard

Open the RAIN OS app, then select RAIN Setup Wizard. The wizard is both a setup path and a readiness checklist. A green or completed step should reflect a durable Salesforce or provider result, not only that a user visited the screen.

Complete required setup first

Use Refresh All Steps after completing a setup action outside the current wizard screen. Do not mark setup complete while a required site, permission, credential, or callback remains unverified.

Add optional operating capabilities

After required setup, the wizard can guide these operational steps:

1. Create an Agent and open the new record to configure, test, and publish it.
2. Add a Phone Number by purchasing a number or synchronizing an eligible existing number, then map it to the intended agent and version.
3. Start Outreach after a published agent and linked phone number are ready.
4. Agent Assignments to determine which agent is eligible for supported record contexts.

Outreach is intentionally blocked until its agent and number prerequisites are met. Assignment availability can vary by release and enabled feature set.

Launch checklist

• The intended users have the RAIN OS app, tab, object, field, Apex, component, and record access required for their jobs.
• Required terms, site, webhook, service URL, and provider configuration are complete.
• At least one low-risk agent is configured, tested with representative context, and published.
• Phone and messaging senders are approved and mapped where those channels are used.
• Quiet hours, consent, suppression, assignment, approval, and autonomous-action policies are documented.
• A controlled outreach or suggestion test produced the expected Salesforce and provider records.
• Owners know where to review Communications, RAIN Hub, Error Log, reports, scheduled work, and provider status.

If setup will not complete

Check the step's actual record or endpoint, the running user's permission, setup status refresh, service banner, browser errors, and Salesforce error logs. When the wizard reports that outreach is not ready, verify a published eligible agent version and linked phone number before recreating either record.

Find RAIN Hub

RAIN Hub is available as a RAIN OS application tab and as a utility item when assigned. It can present:

• Inbox, the default attention and work queue.
• AI Insights, generated observations and recommendations.
• Intelligence, the optional hosted reasoning and workspace experience.

The utility label and highlight can update when new Inbox or insight events arrive.

Work the Inbox

The current Inbox attention queue is centered on eligible Leads and Opportunities. Use search, sort, filters, ownership, priority, score, category, record type, time, and configured display chips to narrow the list. Open the underlying Salesforce record before acting. Depending on the item and permissions, actions can include claiming work, marking read, opening the record, creating or updating a Task, Event, or Communication, and approving or rejecting a next-best action.

Mark All Read acknowledges visible attention items; it does not complete their underlying work. Inbox Display Chips control which selected record values appear on cards and can be customized without changing the business records.

Review AI Insights and suggestions

Evaluate the evidence, target, proposed action or value, confidence, freshness, ownership, and permission boundary. Approve only when the current record still supports the recommendation. After approval, verify the resulting Salesforce record or field. Reject stale, unsafe, incorrect, or unnecessary suggestions and preserve the reason when requested.

Understand completion

An Inbox action is complete when the intended durable result exists and responsibility is clear. A submitted provider action can still be queued. A read item can still have an open Task. A suggestion can show approval while a later provider or background action is pending. Follow the chain through Salesforce status, queued work, provider result, and reconciliation.

Troubleshooting

For missing items, confirm first that the record is an eligible Lead or Opportunity, then review filters, read state, ownership, queue or team eligibility, record sharing, the event source, and background processing. The source query is bounded and the interface paginates results, so a large population should be narrowed with ownership and filters. For a mismatched count, clear search and filters and account for pagination and event timing. For an inaccessible related record, check sharing separately from RAIN-item access. For missing sound, check the user preference and browser media policy.

Choose the smallest capable agent

Do not select a broader agent type solely for future possibility. Every enabled channel increases configuration, testing, monitoring, and compliance responsibility.

Builder sections vary by type. The current Assistant experience emphasizes version history, knowledge, and assignment rather than the full voice/chat Context and Tools configuration. Sales Coach emphasizes role play, coach inputs, knowledge, and assignment. Voice and chat types expose the sections applicable to their channels. Use the sections actually visible for the selected type as the supported configuration surface.

Agent and version responsibilities

The Agent is the durable identity and type. An Agent Version contains the behavior that is tested and published: model, language, prompt, context, knowledge, tools, variables, channel settings, and post-conversation extraction. Preserve prior versions for traceability and publish intentionally.

An agent can be cloned or converted for another channel where the interface supports it. Review every copied prompt, tool, variable, knowledge source, and channel setting; cloning does not prove that the new use case is valid.

Define the use case before configuration

Write down:

• The audience and channel.
• The business outcome and authoritative Salesforce record.
• Information the agent may read.
• Actions the agent may take, recommend, or never take.
• Consent, quiet hours, disclosure, recording, transfer, and escalation requirements.
• Completion and failure signals.
• The human owner for exceptions.

Readiness criteria

The selected type is appropriate when its required channel, context, tools, and safeguards are available. The agent is ready only after representative tests show correct behavior for normal, incomplete, ambiguous, adversarial, and provider-failure cases.

Structure the prompt

Prompt Manager is the primary place to define agent behavior. Use explicit sections so people and Prompt Assistant can review one concern at a time:

1. Role and business purpose.
2. Audience, channel, and disclosure.
3. Allowed information and authoritative sources.
4. Conversation sequence and required discovery.
5. Tools and the conditions for using them.
6. Actions requiring confirmation or human approval.
7. Prohibited actions and safety boundaries.
8. Escalation, transfer, failure, and end conditions.
9. Output, data-capture, and completion expectations.

Avoid embedding volatile record values in the prompt. Use configured variables and record context. Avoid telling an agent that a tool succeeded before the tool returns a success result.

Use Prompt Assistant

Open Prompt Assistant from Prompt Manager when service access is available. Ask a specific question such as improving transfer rules, reducing ambiguity, or adding a missing refusal condition. The assistant can consider the current prompt, selected knowledge, and supported attachments, then return section-level additions, replacements, or removals.

Review each proposed block and its diff. Accept only changes that preserve the intended role, tools, compliance language, and completion criteria. A revised prompt is not automatically saved or published merely because the assistant generated it.

Current Prompt Assistant modes support analyzing, fixing, rewriting, or creating prompt material. A request can include the draft prompt, recent assistant history, selected knowledge, and supported file attachments. The current interface limits a request to three attachments of up to 5 MB each, five history items, five returned suggestions, and eight selected knowledge sources. These limits are release-specific and the interface is authoritative when it shows a different limit.

Prompt, history, selected knowledge, and attachments are sent to the configured AI service for processing. Current processing can use web search and stored-response capabilities. Do not attach secrets, credentials, unnecessary personal data, internal-only material, or content that the organization has not approved for that service.

Keep prompts maintainable

• Give one instruction a single clear owner and location.
• State precedence when rules can conflict.
• Use positive steps and explicit prohibitions where risk requires both.
• Refer to tools by their configured purpose and expected return, not an assumed implementation.
• Define what to do when context is blank, contradictory, stale, or unauthorized.
• Keep channel-specific voice or chat behavior out of unrelated sections.

Validate every change

Save the draft version, test representative records and manual variables, test unavailable tools and missing context, review transcripts and extracted data, and publish only after approval. If a prompt change affects tools, context, assignment, or channels, include those components in the same regression test.

Separate prompt, context, and variables

• The prompt defines stable behavior and rules.
• Context provides approved record or business information.
• Variables provide named runtime values that the prompt, tools, or provider can reference.
• Object mapping determines which Salesforce record fields can populate those variables for an eligible object.

Keeping these responsibilities separate makes behavior easier to test and prevents volatile customer values from becoming permanent instructions.

Configure Context Manager

1. Select only the Salesforce objects required for the agent's use case.
2. Decide whether record detail and activity history are necessary.
3. Add variables with clear names, business meaning, type expectations, and safe defaults.
4. Map each supported object to the field that supplies each variable.
5. Define behavior for blank, inaccessible, or invalid values.
6. Preview the context using representative records from every selected object.

System variables such as direction and time zone can be supplied by the runtime. The test environment also allows manual values. Manual test values do not prove that production object mapping works.

Design variables safely

Use a stable, descriptive name and one meaning per variable. Do not place secrets, credentials, or unnecessary sensitive data in variables. Treat formulas and derived values as claims that require a known source and refresh behavior. When a variable controls a tool or high-impact action, validate its allowed values before execution.

Test record mapping

Select a record in the Test Environment and review Live Preview. Confirm the intended values, labels, blanks, relationship traversal, date/time zone, and activity context. Repeat for records with sparse data, unexpected status, restricted sharing, and values near format limits.

Salesforce access remains part of the boundary, but the effective execution identity varies by path. Interactive configuration and Inbox work generally reflect user access, while selected inbound identity-resolution and record-creation paths can use elevated package execution. Administrators must document the effective identity for each enabled channel and tool rather than assuming every read and write is equivalent to the interactive user.

Troubleshooting

For a blank value, check object selection, field mapping, field access, record sharing, source value, relationship, and default. For the wrong value, verify that the selected record and object are correct and that one variable is not being populated by competing mappings. For excessive context, remove unused objects, record detail, activity history, variables, or knowledge rather than relying on the prompt to ignore them.

Prepare the test

Open the agent's Test Environment. Select a representative Salesforce record when the agent uses record context, then review the populated variables and Live Preview. Set inbound or outbound direction as appropriate. For Sales Coach, select the role-play direction, methodology, and coach inputs.

Test data should be non-production or explicitly approved. A browser-based voice test may not support every production phone behavior, including some transfer paths.

Test behavior end to end

Include:

• Normal conversation and expected completion.
• Missing, contradictory, and restricted record context.
• Each tool's success, no-result, validation, timeout, and provider-failure path.
• Confirmation and approval boundaries.
• Silence, interruption, voicemail, transfer, and end behavior for voice.
• Inactivity and escalation for chat.
• Transcript, recording, communication status, extracted fields, suggestions, and Tasks.
• Prompt-injection and requests outside the authorized role.

Review the final transcript and durable Salesforce records. A natural conversation is not sufficient when the wrong record, tool result, or extracted value is stored.

Publish deliberately

Use version history to identify the tested draft. Resolve pending tool validation errors, save configuration, and publish the intended version. Publishing can lock or identify the production version and synchronize it with the configured provider. Confirm that the agent and channel display the intended active version.

Do not edit production behavior without a new testable version and a rollback reference. When a change affects prompt, knowledge, tools, variables, object mappings, phone settings, or assignment, retest the whole affected path.

Release gradually

Start with a controlled user, number, audience, list, or assignment. Monitor Communications, provider status, transcripts, tool requests, suggestions, Error Log, limits, cost, and customer outcomes. Expand only after expected behavior and failure handling are stable.

If test and production differ

Compare the published version, phone or chat mapping, runtime record, variables, permissions, provider synchronization, direction, environment, and enabled tools. Preserve the failing Communication and transcript before retrying. Roll back or remove assignment when the behavior is unsafe.

Add and map a number

Use the Setup Wizard or Phone Numbers tab to purchase a number or synchronize an eligible existing provider number. Review locality, subscription or approval state, and intended channel. Configure separate inbound and outbound agent and version mappings when required.

The phone record can also show add-on states such as messaging, branded calling, or verified-number capabilities. Submitted is not the same as approved; confirm the final provider status.

Provider synchronization is authoritative. A full synchronization can remove local Phone Number records that are absent from the provider response. Confirm provider scope and preserve the current mapping inventory before running synchronization during an outage, credential change, or provider migration.

Configure voice behavior

On the Agent builder and version configuration, review:

• Language, voice, model, and model behavior.
• First speaker and welcome message.
• Pause before speaking or begin-after-silence behavior.
• Voice speed, volume, expressiveness or temperature, and backchannel behavior.
• Speech and interruption settings.
• Call duration, silence timeout, voicemail detection, and voicemail message.
• Transfer conditions and destination.
• Post-conversation data extraction, transcript, recording, and follow-up.

Current configuration ranges include first-speaker pause from 0 to 5 seconds, begin-after-silence from 0 to 20 seconds, voice speed from 0.5 to 2, voice temperature and volume from 0 to 2, call-silence timeout from 10 to 1,800 seconds, maximum call duration from 1 to 120 minutes, and ring duration from 5 to 90 seconds. Chat inactivity can be disabled or configured from 0.1 to 72 hours. Treat the active UI help as authoritative if a later release changes a range.

Use natural language and clear disclosure appropriate to the organization's policy. Avoid a welcome message that claims knowledge, consent, identity, or success not established by the call context.

Validate inbound and outbound separately

Inbound and outbound calls differ in initiation, disclosure, context, quiet-hour obligations, and first-speaker behavior. Test each mapped direction with the actual number. Confirm the correct agent and version, caller identity, context variables, tools, transfer, end state, Communication record, transcript, recording, extracted values, and follow-up Task.

Troubleshooting

Build an Outreach List

An Outreach List connects an audience definition with a published agent, channel, policy, and execution controls. Configure:

• Object and member type.
• Source list view or supported query context.
• Outreach goal and additional instructions.
• Mode, allowed actions, and execution policy.
• Agent and published version.
• From number and the recipient phone field.
• Quiet hours and time zone.
• Cross-list cooldown, redial wait, immediate and maximum redials.
• Reserved concurrency, refresh interval, and run selection.

Preview the audience and exclusions before execution. A list view is not automatically a compliant audience; verify consent, suppression, ownership, duplicate records, prior contact, quiet hours, and the use case.

Choose voice calls or NBAs

Voice outreach creates or schedules communication attempts through the selected agent and number. Next-best-action mode generates recommendations for review or eligible execution. Define whether an action is advisory, approval-required, or autonomous and which actions are allowed.

Current NBA action choices include SMS, Email, Task, Event, AI Voice Call, and Call Task. Execution policy can be Recommend Only or Use Org Defaults. Channel confidence and autonomy settings still govern execution; a manual batch request does not bypass a disabled autonomous action.

Use the Outreach List record and batch viewer to follow total, pending, queued, completed, failed, invalid, and not-connected work. Stop or abort through supported controls; do not edit status fields to simulate cancellation.

Configure assignment rules

Assignment rules connect an object context to an eligible Assistant agent. Active rules are evaluated by object and ascending priority; the first matching rule with a usable latest published Assistant prompt wins. A rule includes the target object, active state, priority, conditions, condition logic, and optional advanced formula. Keep conditions mutually understandable and priorities deliberate. When several rules can match, test which one wins.

Use straightforward comparisons and the supported logical functions. The runtime supports comparisons plus AND, OR, NOT, ISBLANK, ISNULL, CONTAINS, BEGINS, and ISPICKVAL. Do not rely on an advanced expression merely because an editor accepts its syntax; confirm it against representative records.

Assignment does not override object, field, record, tool, channel, or provider permissions. It selects an agent candidate within those boundaries.

Completion and safe retries

Outreach is complete when every member has a final supported status and the resulting Communications, suggestions, Tasks, or follow-up can be opened. Provider acceptance alone is not delivery or conversation completion. Before retrying a failed or not-connected member, review attempt history, cooldown, redial policy, reply state, and prior results across lists.

Troubleshooting

For an empty audience, check the selected object, list view, filters, access, phone field, and eligibility. For locked outreach, verify a published agent and linked number. For the wrong agent, review active assignment rules, condition logic, priority, record values, and published versions. For missing NBAs, review execution policy, allowed actions, confidence and approval rules, record context, and processing status.

Access is layered

RAIN OS access is the intersection of several controls. A permission set can grant object, field, class, tab, or custom-permission access, but it does not override a missing Salesforce license, record sharing, restriction rules, or the access of an external integration credential.

Evaluate access in this order:

1. Salesforce user and feature licenses.
2. RAIN OS permission-set assignment.
3. Object and field permissions.
4. Organization-wide defaults, roles, teams, queues, and sharing.
5. RAIN custom permissions and feature settings.
6. Provider or hosted-service authorization.

Packaged roles

RAIN OS Admin grants broad application, setup, and operational access, including administrative custom permissions. It is appropriate for the small group that configures agents, providers, billing, automation, and package behavior.

RAIN OS User supports routine use of agents, communications, outreach, suggestions, insights, and related UI. Review its broad record access against the organization's sharing model before assigning it at scale.

RAIN Intelligence User is a narrow custom-permission gate for the optional hosted interface. Users also need an active hosted connection and appropriate Salesforce access.

RAIN OS Guest Permission is narrowly intended to let a configured Salesforce site receive approved integration traffic. Guest execution has a different trust profile from authenticated user execution. Keep the guest user private, grant no interactive application access, and enable the permission only after reviewing endpoint authentication, field access, and logging.

Administrative responsibilities

RAIN OS administrators manage:

• Feature toggles and autonomy choices.
• Agent definitions, versions, assignments, and publication.
• Provider connections, sender identities, phone numbers, and credit status.
• Scheduled work and asynchronous failures.
• RAIN Intelligence enablement and connection state.
• Report and dashboard visibility.

Separate these duties where practical. In particular, a user who reviews suggestions does not normally need provider credentials, package setup, or billing control.

Configuration security

RAIN OS uses package-managed settings for feature behavior and integration configuration. Some settings are protected from subscriber code, but protected storage does not replace credential lifecycle management.

Administrators should:

• Enter credentials only through the supported setup surface.
• Avoid placing secrets in Flow variables, formulas, debug messages, reportable fields, or support screenshots.
• Rotate credentials when an administrator leaves, a provider reports exposure, or the integration scope changes.
• Use a dedicated least-privilege integration identity where the provider supports one.
• Revalidate webhooks and callouts after rotating a secret or changing a domain.

Do not infer that a connected provider has the same access as the user clicking a button. The provider acts with the credential configured for that integration.

Automation and autonomy

Feature settings can allow eligible recommendations or actions to execute with less review. Configure autonomy by business impact, not convenience. Start with explicit review, validate the generated inputs and resulting records, then relax only the action types and confidence bands that have stable outcomes.

Salesforce permissions remain a final control, but system-context automation may have broader execution rights than an interactive user. Test with representative non-administrator users and inspect the resulting record ownership and sharing.

Access review

Review RAIN OS access at installation, quarterly, and whenever roles or integrations change:

1. Export current permission-set assignments.
2. Confirm each administrator still needs setup, billing, and provider control.
3. Confirm ordinary users can access only the records required by their role.
4. Verify guest access is still required and constrained.
5. Review active scheduled work and autonomous action settings.
6. Validate provider and hosted-service credentials and owners.
7. Test access-denied behavior for one user in each role.

Troubleshooting access

When a user sees a missing tab, first check app navigation and permission assignment. When a record is visible but a field or action is not, check field access, component visibility, custom permissions, and record state. When a request starts but the integration fails, check the configured credential and provider authorization. When only some records fail, check sharing, ownership, and record-specific validation rather than broadening the permission set immediately.

Agent and version roles

An agent is the durable Salesforce definition for a business role. An agent version is a revision of its instructions, model or channel behavior, tools, knowledge, and provider configuration. Keeping those concepts separate lets administrators prepare a change without silently altering the active experience.

Assignments determine where an agent applies. Channel configuration determines whether a version is used for voice, chat, or another supported interaction. A published version is the version intended for live use; a draft remains editable and should not be treated as active.

Prerequisites

Before creating an agent:

• Define the user job, audience, permitted data, and success criteria.
• Confirm the channel and provider are configured.
• Identify required Salesforce tools, Flows, and knowledge.
• Decide who may edit, review, publish, and operate the agent.
• Select a test record set that contains realistic success, empty, access-denied, and validation-failure cases.

Create and revise an agent

1. Create the agent definition with a clear business purpose and owner.
2. Create or clone a draft version.
3. Configure instructions, channel options, tools, variables, and knowledge.
4. Add assignment rules only after the draft has a testable behavior.
5. Validate the draft against representative records and users.
6. Review provider-specific settings and expected data transfer.
7. Publish or synchronize the version.
8. Confirm the provider and Salesforce show a consistent active state.

Use a new version for material behavior changes. Editing a draft is appropriate while testing; changing active behavior without a reviewable version weakens rollback and auditability.

Publishing and synchronization

Publishing can require an external provider call. Salesforce records the local lifecycle, while the provider may return its own identifier and status. A local save does not guarantee that remote synchronization completed.

After publishing, verify:

• The intended version is active.
• Required tools and knowledge are attached.
• The provider reports a usable agent where a provider is required.
• The correct phone number, chat entry point, or assignment uses the version.
• A low-risk test interaction produces the expected Salesforce activity.

If knowledge or a tool changes, the affected provider-backed version may require synchronization again.

Clone and convert operations

Cloning creates a new starting point while preserving the original agent. Conversion actions can prepare an agent for another supported channel, but channel-specific settings still require review. Voice needs telephony, pronunciation, transfer, and post-call choices that chat does not. Chat needs entry-point and response behavior that may not apply to calls.

Treat conversion as configuration assistance, not proof of channel readiness.

Permissions and ownership

Agent administrators need access to the agent, version, tool, assignment, knowledge, and provider setup records involved. Operators may need only the published experience and related business records. Keep publish rights narrower than routine use rights.

Record sharing can also affect testing. An administrator's successful test does not establish that a standard user or runtime integration can read the same records.

Troubleshooting

A draft cannot publish: Check required fields, version status, tool validation, provider configuration, and access to linked records.

Salesforce says published but the channel uses old behavior: Check remote synchronization, the version selected by the assignment or phone number, and cached provider state. Avoid repeatedly publishing until the first request's status is understood.

Knowledge changes are absent: Confirm the knowledge link is active and the version has been synchronized after the change.

Only one user or record type fails: Test sharing, field access, assignment criteria, and required merge data with that context.

A conversion produces incomplete behavior: Review every channel-specific setting and republish only after a channel test.

Automation surfaces

RAIN OS supplies active Salesforce Flows for suggestion lifecycle work, scheduled ownership updates, scheduled SMS, and scheduled voice calls. It also supplies invocable Apex actions for communication, voice, formatting, synchronization, and the optional RAIN Intelligence service.

The Flow owns orchestration in Salesforce. The invocable action owns its bounded operation. An external provider or RAIN Intelligence may own a later stage.

Design an automation

Before adding a RAIN action to a Flow:

• Identify the triggering event, entry criteria, and duplicate-prevention rule.
• Define required inputs and their behavior when blank.
• Determine whether the action performs DML, a callout, or queued work.
• Confirm the Flow user and runtime context can access the target records and fields.
• Map outputs and fault paths to an observable status or operator queue.
• Test interaction with existing Apex, validation rules, and other active Flows.

Avoid using an invocable action as an undocumented side effect. A future administrator should be able to tell what request was made and where to inspect its result.

Communication actions

The SMS and voice actions require a valid target, channel configuration, sender or phone context, and provider readiness. The action can create or queue communication work; final delivery or call completion remains asynchronous.

For scheduled work, store the requested time in a consistent Salesforce time-zone context and test daylight-saving transitions. Ensure the scheduled Flow selects each due record once.

Run RAIN Intelligence from Flow

The public Run RAIN Intelligence action accepts a goal plus optional record, object, agent-version, file, model, timeout, execution-mode, safety-gate, and destination choices. It returns success and status information, a run reference, result or summary data when available, action details, and an error when the request fails.

Use synchronous execution when the Flow needs the hosted result before continuing and the task can finish within the transaction's practical callout time. Use background execution when the Flow only needs to enqueue the request.

Background mode queues Salesforce work and returns queue acceptance. It does not return the completed hosted analysis to the Flow or automatically update the source record. Do not design a later Flow decision as though a queued response contains the completed result.

Safety-gate choices range from planning or asking before changes to broader autonomy. Use review-oriented modes for writes, deployments, customer-visible actions, and ambiguous record targets.

Outputs and errors

Handle these outcomes explicitly:

• Completed: inspect returned result and any action details.
• Queued: persist the queue reference if operators need to trace it; do not treat it as completion.
• Blocked or awaiting input: route to review rather than retrying automatically.
• Failed: store a safe error summary and the affected record, then stop duplicate retries.
• Partial: preserve useful output but flag that not every requested action completed.

Do not place credentials, full sensitive prompts, or unrestricted provider responses into Flow fault emails or broadly visible fields.

Troubleshooting

The Flow cannot find an action: Check package version, action access, Flow type, and whether the user can run Apex.

Inputs are rejected: Compare required values and data types, then check null handling and record context.

A synchronous hosted call times out: Narrow the goal or use background mode only when completion is not needed in the same Flow.

A background request never updates the record: Background mode does not update the source record with a completed result. Add an explicit supported persistence step or use synchronous execution for that requirement.

The Flow runs twice: Review trigger criteria, prior-value checks, recursion, scheduled selection, and downstream record updates before adding another guard.

Communication model

RAIN OS uses a common Salesforce communication record for supported SMS, voice, and chat activity. The record holds the channel, sender and recipient context, message or call details, lifecycle status, provider references, and failure information. Email composition uses Salesforce email behavior and its native activity records.

A communication record is the operational audit point. A composer confirmation means Salesforce accepted the request. Delivery succeeds only when the configured provider processes it and RAIN OS receives or reconciles the result.

Prerequisites

Before enabling a channel:

• Configure and authorize a supported provider.
• Synchronize or create an approved sender identity.
• Confirm recipient fields and consent rules for the business process.
• Assign users access to the composer, communication records, and source records.
• Validate available credits, provider account status, sending limits, and any call-center configuration.
• Review templates and merge fields for missing-data behavior.

Provider availability varies by channel and organization configuration. A provider name in package capability does not mean it is enabled in every subscriber org.

Send a communication

1. Open the communication composer from the relevant record or RAIN OS workspace.
2. Select the channel and an approved sender.
3. Resolve or enter a valid recipient.
4. Select a template or enter content, then review all merged values.
5. Send immediately or choose a supported scheduled time.
6. Confirm that a communication record was created.
7. Monitor its status until it is sent, delivered, failed, or otherwise reaches the provider's terminal state.

For bulk or automated outreach, validate one representative communication before increasing volume.

Templates and merge values

Templates improve consistency but can fail when a source record or merge value is missing. A preview is the correct place to catch an empty name, stale phone number, invalid link, or text that exceeds provider limits.

Treat template edits as behavior changes. Re-test each channel that uses the template, especially when a merge value crosses object relationships or depends on optional data.

Scheduling and asynchronous delivery

Scheduled SMS is selected and dispatched by Salesforce automation when its due time arrives. Provider dispatch then happens asynchronously. The scheduled time, Salesforce job execution, provider acceptance, and final delivery are separate events.

Do not create a second message merely because the status has not advanced immediately. First determine whether the record is waiting for its scheduled time, queued for dispatch, accepted by the provider, or awaiting a delivery update.

Status and reconciliation

Use status, timestamps, provider references, and error details together:

• A pending or queued record has not reached final delivery.
• A sent record was accepted for sending but may not prove handset delivery.
• A delivered state reflects provider confirmation when that provider supplies it.
• A failed state should include enough category or detail to correct the input, credential, credit, or provider issue.

Inbound communications and provider callbacks can update an existing thread or create related activity. Reconciliation handles delayed provider results and should be allowed to finish before manual duplication.

Security and compliance

Limit who can select high-trust senders or view sensitive message content. Follow the organization's consent, opt-out, quiet-hours, recording, and retention policies. Salesforce sharing controls who can view the communication record; the provider independently stores or processes data under its own agreement.

Troubleshooting

No sender is available: Check provider connection, sender synchronization, channel support, user access, and sender status.

The recipient is rejected: Confirm format, required country information, source-field access, consent state, and provider restrictions.

The record remains pending: Check scheduled time, asynchronous jobs, dispatch eligibility, credits, and provider availability.

The provider accepted the request but status is stale: Check callback or reconciliation health before resending.

Merged content is wrong: Correct the source data or template mapping and create a new reviewed message; do not overwrite an already sent audit record.

Three related outputs

An insight explains a detected pattern, event, or piece of decision support. A suggestion proposes a reviewable change or next action. A RAIN score provides a prioritization signal for supported records.

These outputs can be related, but they do not have the same lifecycle. An insight can be useful without changing a record. A suggestion is not applied until its action succeeds or configured autonomy permits it. A score should be interpreted with its profile, refresh time, and the quality of available data.

How results are created

RAIN OS can generate analysis after relevant Salesforce activity, through asynchronous processing, by scheduled refresh, or from an enabled agent or provider workflow. The result is written to Salesforce for review and reporting.

Generation depends on accessible source data, configured models or providers, eligible record state, feature settings, and asynchronous capacity. The absence of a result may mean the record was ineligible or processing failed; it does not always mean that the analysis found nothing.

Review an insight

Review the subject record, source activity, creation time, summary, confidence or supporting context, and whether more recent data changes the conclusion. Use the insight to inform work; verify consequential facts in the authoritative Salesforce record or connected system.

Mark or manage the insight through the supported UI so view and disposition history remain available to reporting.

Review and apply a suggestion

1. Open the suggestion and its target record.
2. Confirm the proposed field change or next-best action is still relevant.
3. Check the evidence, confidence, current field value, ownership, and downstream automation.
4. Approve, reject, or defer using the supported status action.
5. Confirm the record change or action actually succeeded.
6. Review any follow-on communication, Flow, or provider status separately.

RAIN OS should not mark an unsuccessful field update as a successful approval. If a suggestion remains unapproved, inspect the application error rather than changing the status manually.

Autonomous settings can approve eligible suggestions based on action type and confidence. Keep sensitive fields and customer-visible actions under explicit review until production outcomes are stable.

Use RAIN scores

RAIN scoring supports prioritization for configured record types. Administrators define or train the scoring profile, queue refresh work, and backfill eligible records. Users should interpret the score as one signal alongside stage, age, activity, owner context, and source-data completeness.

Scores can become stale when source data changes or scheduled refresh is delayed. Confirm the score's last update before using it for a large assignment or outreach decision.

Permissions and side effects

Users need access to the insight or suggestion and its target record. Applying a suggestion can trigger validation rules, Flows, Apex, assignment rules, or external integrations. Test the complete transaction with a standard user, not only an administrator.

Troubleshooting

No insight or suggestion appears: Check feature settings, eligibility, source activity, provider configuration, asynchronous jobs, and record access.

Approval fails: Check current field value, field access, validation, record lock, sharing, and downstream automation.

A duplicate proposal appears: Compare target, action, prior approved history, and generation timing before acting on either record.

A score is blank or stale: Confirm the record type is included, the scoring profile is active, training or backfill completed, and refresh automation is healthy.

Results look systematically wrong: Pause autonomous action, sample both positive and negative outcomes, inspect source-data completeness, and retrain or reconfigure only after identifying the bias.

Prerequisites

RAIN OS is the first package in the RAIN product installation order because it declares no package dependencies and owns the Salesforce data model used by its optional integrations.

Before installation:

• Confirm the target Salesforce edition supports the package features and required API access.
• Use an installer who can install managed packages, assign permission sets, schedule Apex, and configure any required site or integration access.
• Decide which users are administrators, standard RAIN OS users, hosted RAIN Intelligence users, and, only when required, site guest users.
• Inventory existing scheduled jobs, communication providers, call-center configuration, and automation that could overlap with RAIN OS.
• Establish a sandbox validation and rollback plan for upgrades.

Installation lifecycle

The package install starts a post-install process. The synchronous portion establishes runtime access, assigns the installer administrative access, initializes critical communication defaults, and requests deferred setup. On a fresh install it also enables initial application navigation. An upgrade preserves existing configuration where possible and does not repeat every fresh-install presentation step.

Deferred initialization performs independent setup operations such as metadata synchronization, agent seeding, provider synchronization, credit defaults, site setup, scoring refresh, and scheduled work. These operations are deliberately isolated so one failed integration does not roll back every successful setup step.

That isolation also means package installation can finish while one or more capabilities remain uninitialized. Treat installation success as the start of validation, not proof that every feature is ready.

Post-install validation

After installation or upgrade, verify:

1. The installer has the intended administrator permission set and ordinary users have only the access they need.
2. The RAIN OS application and required tabs are visible to the intended users.
3. Agent, communication, insight, suggestion, outreach, and phone records can be opened according to role.
4. Expected scheduled or queued work exists once, with no obsolete duplicate schedule.
5. Default settings exist without replacing subscriber-managed values.
6. Provider connections, phone-number synchronization, and hosted-service connection status match the features being enabled.
7. The default agents needed by the organization exist and can be opened before publication.
8. Reports and the dashboard are accessible through the intended folders and running-user context.

Repeat the validation after a sandbox refresh, credential rotation, package upgrade, or material permission change.

Assign access

Use the packaged permission sets as role starting points:

• RAIN OS Admin is broad operational and setup access. Assign it only to trusted administrators.
• RAIN OS User supports ordinary application work but still depends on Salesforce licenses, object access, and record sharing.
• RAIN Intelligence User enables the optional hosted entry point; it does not configure or license the hosted service by itself.
• RAIN OS Guest Permission is for a specifically configured guest integration path. Do not assign it to human users or a site guest unless that endpoint is required and reviewed.

The installer receives administrative access automatically. Other administrators and users still require deliberate assignment.

Upgrade procedure

For an upgrade:

1. Read the release scope and identify changed objects, automations, permissions, provider contracts, and reports.
2. Test the upgrade against representative configuration and data in a sandbox.
3. Record existing settings, active agent versions, provider connections, scheduled jobs, and critical report totals.
4. Install with a user who can complete post-install work.
5. Re-run the post-install validation and compare results with the recorded baseline.
6. Exercise one low-risk transaction in each enabled channel before resuming high-volume automation.

Do not delete or recreate settings merely because a new default was introduced. Initialization is intended to backfill missing defaults while retaining existing choices.

Troubleshooting initialization

If one area is unavailable while the application otherwise loads, treat it as partial initialization. Review Salesforce setup logs, scheduled jobs, asynchronous job failures, provider status, and the affected RAIN OS record. Retry only the failed setup or synchronization after correcting its prerequisite.

If a job appears more than once, pause the affected automation before removing a duplicate. Confirm which schedule is current and whether the old schedule is still producing work.

If tabs or components are missing, distinguish permission assignment from application navigation and Lightning-page activation. If a provider feature fails, confirm its connection separately from package installation. If RAIN Intelligence is unavailable, validate the hosted compatibility checklist without changing standalone RAIN OS configuration.

Start with the affected record

Most RAIN OS processes leave a Salesforce record that identifies the request and its status. Start there instead of retrying from the UI. Record the channel or feature, current status, relevant timestamps, target record, user role, and whether a provider reference exists.

Classify the failure stage:

1. UI or permission prevented submission.
2. Salesforce validation rejected the input.
3. Apex or Flow failed before queueing work.
4. Asynchronous work failed or remains queued.
5. The provider rejected or delayed the request.
6. A provider callback or reconciliation step failed.
7. Post-processing failed after the primary action succeeded.

This classification determines whether a retry is useful and reduces duplicate communication or record changes.

Common checks

Access: Permission-set assignment, object and field access, record sharing, app navigation, component visibility, and integration credential scope.

Configuration: Feature enablement, provider connection, sender or phone status, active agent version, required templates and knowledge, and credit availability.

Data: Required fields, valid recipient, current record state, ownership, consent, merge values, and validation rules.

Automation: Flow entry criteria, duplicate guards, scheduled time, Apex jobs, platform-event delivery, locks, and limits.

External service: Authorization, account state, provider status, request limits, callback processing, and remote identifiers.

Retry decisions

Retry only after identifying a transient stage and confirming the original request will not still complete. Good retry candidates include a temporary provider outage or a corrected expired credential. Bad retry candidates include invalid input, missing consent, a validation rule, insufficient access, or an ambiguous status with no reconciliation check.

For communications and calls, use the existing provider reference and terminal status to prevent duplicate customer contact. For suggestions, confirm the target record was not already changed. For agent publication, check whether the provider accepted the first synchronization.

Scheduled and asynchronous work

Use Salesforce's scheduled-job and asynchronous-job views to find failed, aborted, or long-running work. Correlate job time with the affected RAIN OS record. A successful parent job can still enqueue child work that later fails.

If a schedule is duplicated, pause the feature before changing jobs. Identify the current schedule and inspect whether both jobs selected the same work.

Safe support evidence

Provide:

• Product and package version.
• Feature and channel.
• Approximate event time and time zone.
• Salesforce record type and a support-safe reference.
• User role and permission-set category.
• Current status and sanitized error category.
• Whether the issue is reproducible in a sandbox.
• Recent upgrade, credential, provider, or automation changes.

Do not provide credentials, tokens, full private endpoints, message content, recordings, transcripts, or unrestricted debug logs unless an approved secure support process explicitly requires them.

Recovery priorities

Protect customers and data first. Pause high-volume or autonomous work if duplicates, incorrect targeting, permission expansion, or unreviewed writes are possible. Preserve records and provider references for investigation. Restore read-only and review workflows before resuming autonomous or bulk execution.

If only RAIN Intelligence is affected, isolate hosted-dependent entry points and keep verified standalone RAIN OS functions available.

Outreach model

An outreach list defines a Salesforce audience and a repeatable communication or action process. RAIN OS can generate list members or communication work, preview next-best actions, and route eligible actions for human review or configured autonomous execution.

The recommendation is not the action itself. Audience generation, recommendation, approval, communication dispatch, provider delivery, and business response each have their own status.

Prerequisites

• Define the campaign purpose, audience criteria, channel, sender, and owner.
• Confirm source records contain usable contact data and required consent.
• Configure the communication provider and templates.
• Establish duplicate, recent-contact, inbound-reply, quiet-time, and exclusion policies.
• Decide which action types always require review.
• Validate confidence and timing settings in a sandbox or limited audience.

Build and preview an outreach list

1. Create the outreach list and select the intended source population.
2. Configure filters, channel, template, sender, and schedule.
3. Generate or refresh the list.
4. Review included and excluded records, especially boundary cases.
5. Preview next-best actions and merged content.
6. Correct source data or criteria before approving work.
7. Release a small batch and monitor through delivery and response.

Refreshing a list can change eligibility as source data, prior communication, replies, or timing changes. Record the business meaning of the filters instead of assuming a previous audience remains valid.

Recommendation safeguards

RAIN OS can suppress or defer outreach when it detects recent contact, duplicate work, an inbound reply, an ineligible schedule, or a disabled feature. Confidence thresholds and per-action settings can determine whether an eligible recommendation remains for review or proceeds automatically.

These controls reduce obvious duplication but are not a complete consent or compliance system. Keep authoritative consent and exclusion data in the organization's approved process and test how it maps to outreach eligibility.

Approve or reject an action

Review the target record, proposed channel, content, sender, timing, and reason. Approving authorizes the next processing stage; it does not prove delivery. Rejecting should preserve the recommendation outcome for later evaluation.

If edits are required, change the source or proposal through the supported workflow, then re-preview it. Avoid approving one proposal and manually sending a materially different communication outside the audit trail.

Autonomous execution

Enable autonomous execution only for reversible, well-tested actions with reliable inputs. Start with a small scope and monitor false positives, duplicate suppression, provider failures, customer replies, and actual outcomes.

RAIN OS does not guarantee a fully closed-loop campaign. Operators remain responsible for reviewing exceptions, stale records, unhandled replies, and actions that could not complete.

Troubleshooting

Expected records are missing: Review list filters, ownership and sharing, contact data, consent, recent outreach, replies, and schedule eligibility.

Unexpected records are included: Pause release, inspect the filter and suppression inputs, and correct the list before dispatch.

A recommendation does not execute: Check approval state, confidence and action settings, due time, feature enablement, required sender and recipient, and asynchronous failures.

Duplicate contact occurred: Stop the batch, compare communication records and provider references, then review claim, retry, and suppression timing before resuming.

Delivery succeeded but no follow-up appears: Check whether the provider supplied the expected callback and whether the reply or post-delivery process is enabled for that channel.

What RAIN OS is

RAIN OS is a managed, Salesforce-native application for configuring agents, communication channels, outreach, suggestions, insights, scoring, and Salesforce automation. Its records, Apex services, scheduled work, reports, and primary user interfaces run in Salesforce.

The package has no declared package dependency. Install RAIN OS before any optional product that integrates with it. A customer can use RAIN OS without connecting RAIN Intelligence, subject to configuring the Salesforce-native features and any communication or AI providers those features require.

Standalone capabilities

RAIN OS owns the Salesforce records and workflows for these capability areas:

• Agent definitions, versions, tools, assignments, and publication lifecycle.
• SMS, voice, chat, and related communication activity.
• Phone-number and voice-agent administration.
• Outreach lists and next-best-action review.
• Insights, suggestions, and RAIN scoring.
• Invocable actions and scheduled Salesforce automation.
• Lightning application surfaces, record pages, reports, and a usage dashboard.

Some capabilities call external providers. "Salesforce-native" describes where the application and operational records live; it does not mean that every message, call, or model operation is performed entirely inside Salesforce.

The optional RAIN Intelligence boundary

RAIN Intelligence is a separately operated hosted service. It adds persistent chat, multi-model routing, retrieval, generated artifacts, gated hosted tools, background analysis, and vertical intelligence. It is not Salesforce metadata installed from the RAIN Intelligence source checkout.

RAIN OS supplies the Salesforce-side permission gate, configuration, Lightning entry point, and Flow action used to reach the hosted service. Without that connection, hosted chat and hosted automation are unavailable, but the rest of RAIN OS does not become unusable.

Records and results

RAIN OS writes results to the Salesforce records that own each process. For example, communication status remains with communication activity, agent publication state remains with agent versions, and reviewed recommendations remain with suggestion or insight records. Provider identifiers and error details may also be retained to support reconciliation.

Use Salesforce sharing, field access, audit history, reports, and operational status fields to understand who can see a result and whether a process completed. A successful UI submission means the request was accepted; asynchronous work or an external provider may still be processing it.

Choosing the right documentation family

Use the RAIN OS articles for Salesforce installation, permissions, agents, communications, outreach, suggestions, scoring, automation, and Salesforce UI behavior.

Use the RAIN Intelligence articles for hosted connection setup, chat, models, retrieval, artifacts, hosted voice, billing modes, the web workspace, and hosted-service health. When a workflow crosses both products, troubleshoot the Salesforce request and the hosted execution as two linked stages.

Boundary checks

Before enabling a feature, identify:

1. The Salesforce record and permission set that own the workflow.
2. Whether the workflow requires a communication provider, an AI provider, or RAIN Intelligence.
3. Which credential is used and what data that credential can access.
4. Whether the result is immediate, queued in Salesforce, or delegated to a provider.
5. Where users and administrators will see completion or failure.

This prevents a hosted-service problem from being treated as a package problem, and it prevents a Salesforce access problem from being treated as a model problem.

Voice lifecycle

RAIN OS manages Salesforce phone-number records and connects them to supported voice agents. An outbound call can be started by a user action, a Flow action, or scheduled communication automation.

The lifecycle has distinct stages:

1. Salesforce validates the number, agent, recipient, and timing.
2. The voice provider accepts or rejects the call request.
3. Provider callbacks update ringing, connected, ended, or failed state.
4. RAIN OS records available duration, cost, outcome, sentiment, recording, transcript, and summary details.
5. Related Salesforce activity is created or updated.
6. Post-call analysis may create insights, suggestions, or coaching results asynchronously.

Not every provider or call supplies every result. Missing sentiment, recording, or transcript is not by itself proof that the call failed.

Prerequisites

• Configure the supported voice provider and verify account status.
• Synchronize, purchase, or connect a phone number through the supported administration flow.
• Attach the number to a published voice-agent version.
• Confirm calling permissions, recipient consent, recording notice, and regional requirements.
• Ensure the runtime user can create communication and activity records.
• Configure post-call processing only after basic call status works reliably.

Configure a phone number

1. Synchronize available numbers from the provider or complete the supported purchase flow.
2. Review number capabilities and ownership.
3. Select the published voice agent that should answer or place calls.
4. Configure supported inbound, outbound, transfer, and add-on behavior.
5. Save and verify remote synchronization.
6. Place a low-risk test call and inspect the resulting Salesforce records.

Changing the linked agent or provider options may require synchronization before the new behavior is live.

Place or schedule an outbound call

Provide the target record, valid recipient number, voice agent or phone number, and any supported call variables. For scheduled calls, also provide a future time in the intended Salesforce time-zone context.

After submission, monitor the communication record. A queued result means the call has not completed. Do not infer the business outcome until the provider sends the terminal status and post-call processing finishes.

Retry or redial behavior must be configured conservatively. Confirm the first attempt is terminal before manually starting another call, and avoid retrying validation, consent, or invalid-number failures.

Post-call results

RAIN OS can retain provider-supplied call metadata and use the transcript or summary for follow-up analysis. Related activity gives Salesforce users a familiar timeline entry, while the communication record remains the channel-specific source for status and provider details.

Recordings and transcripts can contain sensitive personal or regulated data. Restrict their visibility, follow the organization's retention policy, and confirm the provider's storage terms.

Post-call insights and suggestions are recommendations. Review them according to the organization's approval and autonomy settings before relying on them for customer-visible changes.

Troubleshooting

A number does not appear: Recheck provider authorization, number ownership, synchronization status, and user access.

The call is rejected immediately: Validate number format, published agent, provider balance, allowed destination, consent, and required variables.

The call ended but no Salesforce activity exists: Check callback processing, communication-record errors, asynchronous jobs, and activity creation permissions.

There is no transcript or recording: Confirm the provider supplied it, recording was enabled and lawful, the call connected long enough, and callback processing finished.

Post-call analysis is missing: Verify the call reached an eligible terminal state, transcript or summary input exists, analysis is enabled, and the asynchronous job did not fail.

Optional add-on boundary

RAIN Intelligence is not required for standalone agents, communications, phone, outreach, suggestions, scoring, automation, or reporting provided by RAIN OS. It is required for hosted persistent chat, multi-model routing, retrieval, generated artifacts, hosted gated actions, and hosted vertical intelligence.

RAIN OS owns the Salesforce entry point and connection settings. The hosted service owns model execution, hosted storage, retrieval, and web workspace behavior.

Prerequisites

• Install and initialize RAIN OS first.
• Obtain the appropriate RAIN Intelligence subscription or entitlement.
• Establish the supported hosted connection for the Salesforce org.
• Configure the Salesforce-side service connection through the supported administration surface.
• Assign the RAIN Intelligence custom-permission set only to intended users.
• Ensure the connected Salesforce identity has least-privilege access to required records and metadata.
• Review hosted data handling, model providers, billing mode, and safety gates.

Compatibility validation

1. Confirm ordinary RAIN OS pages and records work without relying on the hosted service.
2. Open the RAIN Intelligence entry point as an entitled standard user.
3. Confirm the hosted service identifies the intended Salesforce org and user context.
4. Run a read-only request against a non-sensitive test record.
5. Verify the answer is grounded in the expected Salesforce data.
6. Run a gated low-risk action and confirm the approval behavior.
7. If Flow integration is required, test synchronous and queued behavior separately.
8. Review hosted activity, cost, and failure telemetry for the test.

Do not begin with a deployment, bulk update, customer communication, or broad record analysis.

Access model

The RAIN Intelligence permission set gates the Salesforce UI. It does not grant hosted licensing, create a connection, or broaden Salesforce record access.

Hosted Salesforce operations run through the connected credential available to the service and through RAIN safety policy. Administrators must scope that connected credential appropriately; do not assume every operation automatically has exactly the interactive user's Salesforce permissions.

Flow compatibility

The Run RAIN Intelligence action supports synchronous and background requests. Synchronous mode can return a hosted result to the Flow. Background mode queues Salesforce work and does not return the completed result to the original Flow or automatically update its source record.

Design Flow behavior around the actual response mode. A queue reference is useful for tracing but is not a completed analysis.

Upgrade and incident behavior

RAIN OS and RAIN Intelligence can release independently. After either product changes authentication, request schema, gate behavior, models, or result structure, repeat the compatibility validation.

If RAIN Intelligence is unavailable, pause hosted-dependent automation or route it to review. Do not disable unrelated standalone RAIN OS workflows unless they share a failing provider or configuration.

Troubleshooting

The tab is unavailable: Check the RAIN Intelligence permission set, app navigation, and user entitlement.

The tab opens but does not connect: Check org registration, service configuration, hosted health, and connection authorization.

A read returns no records: Verify the intended org, connected credential, object and field access, sharing, and query scope.

An action is blocked: Review safety-gate mode, action risk, required confirmation, Salesforce validation, and credential permissions.

A Flow queues but no result appears: Queued mode does not update the record with a completed result. Use supported synchronous persistence or redesign the follow-up stage.

Analytics and observability are different

RAIN OS includes packaged reports across agents, communications, delivery, cost, conversion, outreach, insights, suggestions, and next-best actions, plus a communication-usage dashboard. These answer business and operating questions over Salesforce data.

Troubleshooting a single execution requires operational evidence instead: the source record, communication or suggestion status, timestamps, asynchronous job, provider reference, and safe error detail. A dashboard is not a live health monitor for every integration.

Report access

Users need access to the report or dashboard folder, underlying report type, objects, fields, and records. Dashboard results can also depend on its running-user configuration. Two users can see different detail records even when a shared aggregate is visible.

After installation or an access-model change:

1. Assign folder access to the intended groups.
2. Confirm the running-user choice and sharing implications.
3. Open representative source reports as an administrator and a standard user.
4. Verify report filters, date fields, statuses, and units.
5. Compare a small sample with the underlying Salesforce records.

Interpret communication metrics

Communication totals can differ depending on whether the report counts created, queued, sent, delivered, connected, or completed records. Provider callbacks may arrive after the reporting period or update a record later. Scheduled work can be created in one period and delivered in another.

Cost fields depend on provider-supplied or calculated data and may be absent for some channels or failed requests. Use them for operating visibility and reconciliation, not as the sole billing ledger.

Interpret recommendation metrics

Suggestion and next-best-action reports can distinguish generated, viewed, approved, rejected, applied, and failed outcomes. A high approval rate is not enough to establish quality; review whether approved actions completed and produced the intended business result.

Insight counts can reflect generation volume rather than unique business events. Check grouping and duplicate rules before comparing teams or time periods.

Monitor operations

Establish a routine that covers:

• Failed or long-pending communications.
• Provider callback and reconciliation gaps.
• Failed asynchronous and scheduled jobs.
• Suggestions that were approved but not applied.
• Stale scores or delayed refresh work.
• Agent versions that are locally active but not synchronized.
• Credit, limit, or authorization warnings.

Record thresholds and ownership outside the report definition so an alert has a clear responder and escalation path.

Troubleshooting analytics

A report is empty: Check date and status filters, folder and object access, record sharing, and whether the expected process writes that object.

Totals differ from a list view: Compare filters, date fields, report type joins, grouping, and record visibility.

The dashboard is stale: Refresh it and inspect source reports. A refreshed dashboard can still lag an external provider whose callback has not arrived.

Cost is missing: Check whether the provider supplies cost for that event and whether the call reached a billable stage.

A report changed after upgrade: Review field and status changes, subscriber customizations, and the effective report definition before restoring an older copy.

Tool and knowledge roles

Tools let an agent perform a bounded operation, such as reading a Salesforce record, invoking a Flow, sending a communication, posting an internal update, checking availability, booking an appointment, transferring a call, or extracting a structured value.

Knowledge gives the agent approved reference material. RAIN OS can associate Salesforce-managed content with an agent version and synchronize supported material to an external agent provider. This provider-backed knowledge path is distinct from the hosted retrieval system in RAIN Intelligence.

Select tools deliberately

The current catalog includes Agent Transfer, Check Calendar Availability, Transfer Call, Apex Action, Book Appointment, Chatter Post, End Call, Extract Variables, Flow Action, Get Record, Salesforce Action, Custom Notification, Email, and SMS. Availability depends on agent type, provider support, version state, and permissions.

For each tool, document:

• The business purpose and allowed users.
• Required inputs and where they come from.
• The output or Salesforce record change.
• The execution identity and required permissions.
• Whether the action is read-only, reversible, customer-visible, or financially sensitive.
• Expected provider, Flow, validation, and limit failures.

Avoid adding broad tools "just in case." A smaller tool set improves predictable selection and reduces the number of actions that require elevated access.

Configure an action tool

1. Confirm the target Salesforce action or Flow is active and has a stable public input/output contract.
2. Create the agent tool with a user-readable purpose and precise input descriptions.
3. Map only required values. Define behavior for missing record context.
4. Attach the tool to a draft agent version.
5. Test success, missing input, access denied, validation failure, and provider timeout.
6. Confirm the result is written or returned where operators expect it.
7. Publish or synchronize the agent version.

Changing a Flow variable, action signature, or required field can break an existing agent tool even when the agent configuration itself did not change.

Configure knowledge

Use current, approved, scoped material. Remove duplicates and obsolete versions before linking content. For customer-facing agents, review whether the material contains internal-only guidance, personal data, contractual restrictions, or instructions that conflict with the agent's allowed actions.

The knowledge lifecycle is:

1. Add or select the Salesforce content.
2. Link it to the intended agent or version.
3. Start provider synchronization where required.
4. Wait for a usable synchronization state.
5. Test questions that should be answered, should be declined, and should return no result.
6. Re-synchronize after replacing or materially changing content.

Deleting a local link and deleting remote provider content are separate concerns. Confirm both when retiring sensitive material.

Permissions and data handling

The user configuring a tool needs access to its definition; the runtime also needs access to the action, Flow, records, and fields it uses. Knowledge content may leave Salesforce when synchronized to an external provider. Review provider retention and access terms before enabling that path.

Do not use knowledge as a substitute for record-level authorization. An agent should retrieve a live Salesforce fact through an authorized tool when the answer depends on current restricted data.

Troubleshooting

The agent never selects a tool: Make the tool purpose and inputs unambiguous, confirm it is linked to the active version, and verify the channel supports it.

A tool is selected but fails: Check required inputs, Flow or action activation, field access, sharing, validation rules, callout configuration, and asynchronous limits.

Knowledge answers are stale: Confirm the current file is linked, the remote synchronization finished, and the active version uses the updated knowledge.

Knowledge produces no answer: Check file support, content readability, synchronization state, question terminology, and provider availability.

A published version still has old tools: Synchronize the version and verify the assignment or channel points to that version.

RAIN OS application

The packaged Lightning application brings together setup, agents, phone numbers, knowledge, outreach, communications, insights or suggestions, and the optional RAIN Intelligence entry point. It also includes common Salesforce records used in those workflows.

The utility bar provides persistent access to selected productivity and operational tools, including the RAIN Hub and communication-related utilities. Exact visibility depends on permission assignment, app configuration, form factor, and subscriber Lightning activation.

Main work areas

Setup is for administrators configuring features, providers, permissions, metadata synchronization, scoring, and hosted compatibility.

Agents is for agent definitions, versions, tools, knowledge, assignments, publication, and channel conversion.

Communications and phone is for senders, phone numbers, message composition, calls, communication history, and delivery status.

Outreach and recommendations is for outreach lists, next-best actions, insights, suggestions, and review decisions.

RAIN Hub presents operational work and shortcuts. Treat the underlying Salesforce records as the authoritative status when a compact surface omits detail.

RAIN Intelligence opens the optional hosted experience for entitled and connected users.

Record pages and actions

RAIN OS packages Lightning record pages for core agent, phone, outreach, insight, suggestion, and communication work. Quick actions support frequent operations such as cloning or publishing an agent, converting a channel, managing a number, placing a call, or opening a widget.

A packaged page is not necessarily the active page for every app, profile, record type, or device. Administrators should review Lightning activation after installation and upgrades, particularly when the subscriber already has custom record pages.

Communication composers

RAIN OS provides channel-specific and combined composer experiences. The available controls depend on record context, provider configuration, sender availability, user access, and the selected channel.

When a composer opens without expected values, check the source record and permissions before editing the component. When it submits successfully, continue to the communication record to monitor asynchronous status.

Configure visibility

1. Assign the appropriate RAIN OS permission set.
2. Add the RAIN OS app to the user's available applications.
3. Confirm required tabs are visible in the app navigation.
4. Activate packaged or subscriber record pages for the intended app, profile, record type, and device.
5. Review component visibility rules and custom-permission conditions.
6. Test as a standard user with representative record sharing.

Avoid giving broad administrative access solely to make a tab appear. Resolve navigation, object access, and component visibility at their correct layer.

Empty, loading, and error states

An empty list can mean there are no records, the user lacks sharing access, a filter excludes records, or synchronization has not completed. A loading state can represent an Apex request or provider operation. An error should be correlated with the affected record, asynchronous job, or provider status.

If a component repeatedly fails, capture the user role, app, page, record type, record state, action, and time. Do not include credentials or sensitive message content in support evidence.

Troubleshooting navigation

The app is missing: Check permission-set assignment, app availability, license, and whether the user is in the intended Salesforce org.

A tab is missing: Check tab visibility and app navigation independently from object access.

A record uses an older layout: Review Lightning page activation and record-type assignment.

An action is missing: Check page layout action placement, component visibility, record state, and custom permissions.

The RAIN Intelligence tab opens but cannot connect: Follow the hosted compatibility checklist; the tab permission alone is not a hosted connection.