Community Agent
AI funding and usage
AI included uses REDA credits. Bring your own AI uses your organisation’s provider account, billed directly by that provider. The licence selects one funding model for the organisation. In either model, REDA AI governs configured tools and actions in Salesforce. Set up your licence and AI accounts.
If the administrator changes the effective AI connection, model or funding mode, affected chat sessions need a new conversation. Start a new chat when asked; the old account’s conversation cannot simply continue on the new route. For customer accounts, verify credential access for the website guest or signed-in portal identity. See connection permissions.
An agent with Channel = Community is bound to the Experience Cloud / portal surface only. It cannot be invoked from the internal Salesforce LWC, from Flow / Apex (API channel), or from a public-website widget (External Widget). The Community Bridge will only resolve agents whose Channel is set to Community; routing an Internal, API, or External Widget agent to a portal page is rejected with a clear error. Pick the channel that matches the surface you intend to deploy on.
What is the Community Channel?
The Community channel allows you to deploy REDA AI agents to portal users in a Salesforce Community. Portal users log into your community with their own credentials and interact with agents while respecting the portal's security and sharing rules.
Key characteristics:
- Portal User Authentication — Users log in with their community credentials
- Respects Portal Permissions — Agents only access data the portal user can see
- Private Community Access — Agents are embedded in your community pages
- User Context Available — Context variables ({USER_NAME}, etc.) available
- Limited Scope — Portal users typically see only their own records (accounts, cases, contacts)
Setting Up a Community Agent
The agent already knows who it is talking to. Experience Cloud users are linked to a
Contact through User.ContactId. When a community conversation starts, REDA AI resolves that
Contact, stores it as the conversation’s context record, and injects it into the system prompt on
every turn — so the agent has the person’s name, account and whatever other Contact fields you
configured as context, with no client payload and no per-agent setup. A portal user with
no Contact simply gets a conversation without a context record; nothing fails.
One prerequisite worth knowing: the Community Portal Chat platform setting is the master
switch for this channel. It is enabled by default, but if it is turned off every community request
is rejected with DISABLED.
Step 1: Configure the Agent as Community
- Open the Agent Definition
- Set the agent's Channel to Community
- Configure the agent's prompts and tools
- Set appropriate permissions for portal users
- Activate the agent
Step 2: Review Portal User Profile
Before deploying, review your portal user profile's permissions:
- What objects can portal users access? (Cases, Contacts, Accounts, etc.)
- Can they create new records, or only read existing ones?
- Which fields are visible to them?
- Do they have access to Knowledge articles?
The agent will operate within these constraints. If portal users can only read Cases, the agent can only help them view and search cases.
Step 3: Deploy to Community Pages
Use Experience Builder to add the REDA AI Community Chat component to community pages:
- Open Experience Builder for your community
- Create or edit the page where you want the chat widget
- Drag the REDA AI Community Chat component onto the page (a footer or template region works well so it appears on every page)
- Set the Agent Name property to the Agent Id of your community agent (e.g.
reda-portal-assistant) - Customize the appearance using the design properties described below
- Save and publish the community
Widget UI Customization
Select the REDA AI Community Chat component on the canvas to reveal its property panel on the right. Properties are grouped by purpose: Layout & Position, Branding, Launcher Bubble, Header, Welcome Hero, and Advanced.
Required Property
| Property | Description |
|---|---|
| Agent Name | The Agent Id of your community agent definition (e.g. reda-portal-assistant). |
Layout & Position
| Property | Values | Default | Description |
|---|---|---|---|
| Theme | light | dark |
light |
Color theme for the widget. Dark mode uses dark backgrounds with light text. |
| Display Mode | Bubble | Docked Right | Docked Left |
Bubble |
How the chat panel opens. Bubble is a floating card above the launcher. Docked Right/Left is a full-height panel that slides in from that edge — more room for cards, photos and longer answers. The launcher bubble is shown in every mode, and on phones the panel opens full-screen either way. |
| Position | bottom-right | bottom-left |
bottom-right |
Which corner the launcher bubble appears in. Independent of Display Mode — the bubble can sit bottom-left while the panel docks to the right. |
| Open on Page Load | Checkbox | Off | Automatically open the chat panel when the page loads. |
Branding
| Property | Default | Description |
|---|---|---|
| Widget Title | AI Assistant |
Title displayed in the chat panel header. |
| Primary Color | Matches your community | Primary brand color (hex). Used for the launcher bubble, colored header, user message bubbles, and accent text in the welcome hero heading. Leave it blank and the widget automatically picks up your community’s own brand color (from your Experience Builder theme), so it looks like part of the site without any setup. Enter a hex value only if you want to override that. |
| Mascot Image URL | (none) | Optional URL to a custom avatar image. The image is shown in the launcher bubble, the chat header, and as the welcome hero avatar. Square images of at least 200×200 px work best (PNG with transparency recommended). |
Launcher Bubble
The launcher is the floating button portal users click to open the chat. Display it as a circle (default) or a pill-shaped button with a text label.
| Property | Values | Default | Description |
|---|---|---|---|
| Bubble Style | circle | pill |
circle |
Shape of the floating launcher. |
| Bubble Label | Any text | (none) | Label text shown in the pill (e.g. “Ask Maria”). Required for pill style — without a label, the launcher falls back to the circle style. |
Set Bubble Style to pill and Bubble Label to Ask Maria. The launcher displays as a rounded pill with an icon and the text. If a Mascot Image URL is set, the mascot replaces the default chat icon inside the pill.
Header
| Property | Values | Default | Description |
|---|---|---|---|
| Header Style | colored | minimal |
colored |
Colored uses the Primary Color as the header background with white text. Minimal uses a white background with dark text and a subtle bottom border — a cleaner look on light portals. |
Welcome Hero (Empty State)
The welcome hero is a branded greeting shown in the chat panel before any messages exist. It displays the mascot (or a default chat icon), a large heading with the agent name highlighted in your brand color, and optional subtext.
| Property | Values | Default | Description |
|---|---|---|---|
| Show Welcome Hero | Checkbox | On | Show or hide the welcome hero section. |
| Welcome Heading | Any text | “How can [Widget Title] help?” | Hero heading. Use {title} as a placeholder for the Widget Title — the matching portion is rendered in the Primary Color. |
| Welcome Subtext | Any text | (none) | Optional smaller line shown below the heading. |
Set Welcome Heading to How can {title} help? and Welcome Subtext to Ask me anything about your account, leases, or maintenance.. The {title} placeholder is replaced with the Widget Title (e.g. “Maria”) and rendered in your brand color.
End Conversation
Portal users can explicitly end their chat session. When ended, the conversation will not auto-resume on subsequent visits or hard refreshes — the user starts fresh on the next interaction. Records are retained for archival; this only affects whether the conversation resumes.
| Property | Values | Default | Description |
|---|---|---|---|
| Allow End Conversation | Checkbox | On | Shows the End Chat (checkmark-in-circle) button in the widget header. When enabled, portal users can explicitly terminate the conversation. Disable to keep conversations always-resumable. |
| Enable Voice Input | Checkbox | On | Shows a microphone button so portal users can dictate messages instead of typing (speech-to-text). The button appears only in browsers that support voice input, so there is nothing to hide on unsupported ones. Disable to remove it entirely. See Voice Input. |
When the portal user clicks End Chat in the header, an inline confirmation strip appears above the input area asking “End this conversation?” with Cancel and End Chat actions. On confirmation, the conversation is marked ended on the server and the widget shows a centered “Conversation ended” card with a Start a new chat button. The user can resume immediately or close the widget — the next visit will not auto-resume the ended conversation.
If the user has the portal open in multiple tabs and ends the conversation in one, the other tabs detect the ended state on the next message attempt and switch to the “Conversation ended” card automatically — no confusing error messages.
Multilingual Support
All widget UI text (header buttons, confirmation strip, ended-state card, error messages, welcome hero) is sourced from Salesforce Custom Labels and translated automatically based on the portal user’s language preference. To localize the widget for additional languages:
- Open Setup → Translation Workbench → Override
- Select the language and the Custom Labels aspect
- Find the labels prefixed with
REDAAI_Community_(e.g.REDAAI_Community_EndConfirmTitle,REDAAI_Community_EndedHeading) - Provide translated values
- Save — portal users with the matching language will see the translated text the next time they open the widget
If you need to override individual phrases without using Translation Workbench (for example, brand-specific wording in English), use the Advanced Configuration JSON property below to override any widget label key.
Advanced Configuration (JSON)
The Advanced Configuration property accepts a JSON object that can override any widget option — including knobs not exposed as individual properties (typography, mobile breakpoints, internationalization, custom secondary colors). Keys in the JSON object win over the individual properties above, so use this only when the structured properties are not enough.
{
"fontFamily": "'Poppins', sans-serif",
"fontSize": 15,
"panelWidth": 420,
"panelHeight": 600,
"inputPlaceholder": "Como podemos ajudar?",
"errorAuthRequired": "Por favor, faça login para usar o assistente."
}Overrides typography, panel dimensions, and translates the input placeholder and authentication error to Portuguese.
File Attachments
When the agent has Allow File Upload enabled, portal users can attach files to their messages using a paperclip button in the message bar — up to 5 files per message. Each file appears as a named chip on the sent message. Files uploaded in the portal are automatically linked to the signed-in customer's Contact record, and the assistant can attach a file to a related record (such as a Case it raises) when asked. Supported file types and the size limit follow your REDA AI settings. See File Upload for details.
So the agent is comfortable reading uploaded files (rather than declining), make sure its instructions say it can. Newer agents include this guidance; for an existing agent, add a short line to its instructions such as “You can read files and images customers upload and use their contents to help.”
Portal User Permission Set Assignment
REDA AI Community User permission set
The Experience Builder “Members” setting only controls who can log in to the community — it does not grant the underlying object/field permissions. Without this permission set, the chat widget will fail to initialise (the Apex bridge cannot read the Agent Definition or write conversation/message records).
The shipped REDAAI_Community_User permission set grants exactly the access the widget needs to:
- Read the Agent Definition to validate the agent and load its display configuration
- Create and read the conversation and message records owned by the portal user
- Edit the conversation's ended-state and last-activity tracking (required for the End Chat action)
- Read the Tool Definition metadata for the agent’s assigned tools
Three ways to assign at scale
- Manual — Setup → Users → open the portal user → Permission Set Assignments → Edit → add “REDA AI Community User”. Fine for piloting; not scalable.
- Permission Set Group — bundle
REDA AI Community Userwith any other portal-user PSes into a PSG and assign the PSG. Cleaner for orgs with multiple portal user types. - Auto-assign on User create (recommended for production) — build a Flow on the User object that fires when a portal user is created (filter by
IsPortalEnabledor by Profile) and adds the permission set automatically. About 5 minutes to build, zero ongoing maintenance.
The most common cause is a missing permission set assignment. Check Setup → Users → portal user → Permission Set Assignments. The shipped Apex returns generic error codes (not detailed permission errors) by design — for security — so the bridge log is the source of truth. Look for sObject type ... is not supported in the browser console, which masks an underlying access denial.
Lightning Web Security (LWS) requirement
The community widget’s shadow DOM requires Lightning Web Security to be enabled in the host org. Setup → Session Settings → check Use Lightning Web Security for Lightning web components and Aura components. Orgs still on legacy Locker Service will see this.host.attachShadow is not a function in the browser console — LWS is the strategic direction Salesforce is moving to anyway.
Portal User Permissions (data access)
Beyond permission set assignment, community agents respect the portal user's complete permission set when accessing data:
| Aspect | Enforcement |
|---|---|
| Object-Level Access | Agent can only access objects the portal user's profile allows |
| Field-Level Security | Agent can only see fields the portal user has read/write access to |
| Record Sharing | Agent can only access records shared to the portal user (typically just their own) |
| Org-Wide Defaults | Portal-level org-wide defaults restrict access |
| Role Hierarchy | Portal users don't see other portal users' records (typically) |
Typical Use Cases
Portal users log into your customer community. They chat with the Support Agent to:
- View their own support cases
- Check case status and get updates
- Search knowledge base articles
- Create new support cases
Partner portal users use an agent to:
- View their opportunities and leads
- Query co-marketing development funds (MDF)
- Get product information and training links
- Request resources or support
Tools for Community Agents
Assign tools that are appropriate for portal user access levels:
| Tool | Recommended? | Use Case |
|---|---|---|
| soql_query | Yes | Portal users query their own records |
| get_record | Yes | Portal users view details of their records |
| count_records | Yes | Portal users count their own records (e.g. open cases) |
| create_record | Maybe | If portal users should create cases/requests |
| update_record | Rarely | Only if portal users should modify their own records |
| send_email | No | Not recommended for portal users |
How Actions Work on the Community Channel
Unlike the Internal channel (which shows a confirmation card the user clicks), a Community agent auto-executes an Action tool and then automatically replies with the real outcome — e.g. “I’ve logged your request as Case #00001234.” If the action fails, the agent says so honestly rather than implying success. This keeps the portal experience conversational while remaining transparent about every change. The number of automatic follow-up turns is capped by the Max Continuation Depth platform setting (default 3). Assign Action tools to Community agents deliberately and scope portal-user permissions tightly. See Action Confirmations → How confirmations differ by channel.
Security Considerations
Portal users are heavily restricted in what they can see. Each portal user typically sees only their own account, contacts, and cases. Org-wide defaults and sharing rules enforce this isolation. The agent respects these boundaries completely.
Sensitive Field Visibility — Portal users do not have access to sensitive fields like Salary, Internal Notes, or Confidential Data. If you configure such fields as context fields, portal users won't see them (FLS applies).
No Cross-Account Access — Portal users cannot see other accounts' data. If your portal serves multiple partner companies, each sees only their own.
Community Agent vs. External Widget
Choosing between Community and External Widget:
| Aspect | Community Channel | External Widget |
|---|---|---|
| Authentication | Authenticated portal user | Guest (no authentication) |
| User Identity | Known (portal user profile) | Unknown (guest user) |
| Data Access | Portal user's own data + shared | Public data only |
| Deployment | Community pages | External websites |
| Use Case | Existing customers/partners | Prospects/leads |
Best Practices for Community Agents
Always test community agents logged in as a portal user, not an admin. Verify the agent only has access to data the portal user should see.
Use Specific Personas — Create personas tailored to portal users. Example: "You help our partners find the resources and support they need."
Leverage Record Context — Embed agents on record detail pages so portal users can get help while viewing their records.
Minimize Tools — Only assign tools portal users actually need. Too many tools confuse users and may expose unintended data.
Document Limitations — Make it clear in the persona what the agent can help with. Portal users may expect broader access than they actually have.
Review conversation continuity
A blank Conversation Window (Hours) now uses the organisation default, initially 30 minutes. A positive value sets the agent's window; 0 disables automatic resume. Matching remains channel-specific: API uses agent and record context; authenticated Internal/MCP uses agent, user and the relevant record context. Community uses the shared window setting instead of the external-session timeout. Home, app-page and utility-bar chat can resume eligible conversations. Explicit conversation identifiers remain subject to their route's access checks. Review agents that relied on blank meaning a new conversation, and use 0 where that behaviour is required. Packaged permission fixes also address Internal and Community conversation access.
Frequently Asked Questions
No. The agent operates within the portal user's complete permission set, including org-wide defaults. If the user can't see data, the agent can't either.
Yes, if the agent creates a Case or other record that portal users have permission to create. The record is created in your Salesforce org and visible to internal users (subject to sharing rules).
Use the portal user profile's org-wide defaults and sharing rules. Portal users tied to a specific account can only see data for that account. The agent respects this automatically.
Yes. Create separate agents and deploy them to different communities or pages. Each agent can have tailored prompts and tools for its audience.
No. The widget renders inside a Shadow DOM, which means your community’s CSS cannot reach its internal elements. Use the design properties in Experience Builder (or the Advanced Configuration JSON property for power-user overrides) to style the widget.
The pill style requires a Bubble Label. If you set Bubble Style to pill but leave the label blank, the widget falls back to the circle style. Add a short label like “Ask Maria” or “Chat with us” to enable the pill.
They are different things. The welcome message is the first chat message portal users see and is set on the Agent Definition record (External Welcome Message field). The welcome heading and welcome subtext are the branded greeting shown in the empty-state hero before any messages exist — both are configured in Experience Builder via the Welcome Heading and Welcome Subtext properties.
The × close button only minimizes the widget; the conversation remains active and will resume on the next page load. End Chat (checkmark-in-circle icon) marks the conversation as terminated on the server — it will not auto-resume on hard refresh or future visits within the session timeout window. Use End Chat when the portal user is “done” with their question; use Close when they want to step away briefly and return to the same conversation.
Yes. Uncheck the Allow End Conversation property in Experience Builder. The button will not render and conversations will always be resumable until the server-side timeout expires (the session timeout configured on the Agent Definition).
Yes — all widget UI text (buttons, confirmations, ended-state card, error messages, welcome hero defaults) is sourced from Salesforce Custom Labels prefixed with REDAAI_Community_. Use Translation Workbench (Setup → Translation Workbench → Override) to provide translated values for any supported language. Portal users automatically see the text in their language preference. For per-deployment overrides without translation, use the Advanced Configuration JSON property to override individual label keys.
Next Steps
Review data access and permissions to understand security controls, or explore external widget deployment for customer-facing agents. For the equivalent customization options on the public-facing widget, see Widget UI Customization.