Community Engagement Strategy
Use this skill when designing the engagement model for an Experience Cloud community site — covering reputation gamification, ideation workflow, and content contribution strategy. This skill does NOT configure moderation rules, guest user access, or the technical site template.
Before Starting
Gather this context before working on anything in this domain:
- Confirm the Experience Cloud site is already provisioned.
Network is the metadata that carries reputation, and ManagedTopics deploys only against an existing site: "The related Experience Cloud site must exist before you deploy managed topics." (Metadata API Developer Guide, ManagedTopics, api_meta.txt L86723-L86724).
- Clarify which member behaviors the community sponsor most wants to incentivize. There are 16 documented
eventType values and each has a platform default point value; the strategy's job is to decide which of them deviate from the default and why (api_meta.txt L91675-L91711).
- Establish which reputation system is in scope.
Network reputation (Experience Cloud site) and Ideas-zone reputation (IdeaReputationLevel) are separate systems with separate storage and separate rules — see references/gotchas.md Gotcha 6.
- Understand whether content ownership has been decided: who is responsible for each content area (product, support, marketing). Undefined ownership is the most common cause of stale community content after launch.
- Note that reputation points are not retroactive: members who acted before Reputation was enabled will not receive points for historical activity. UNVERIFIED (2026-09-05): not stated in the Metadata API or Object Reference guides; retained as practitioner experience. The remedy is grounded —
NetworkMember.ReputationPoints is updateable and "You can directly update reputation points for a member via the Salesforce API" (object_reference.txt L188591-L188592).
Questions to Ask Before Configuring
Ask these before anyone opens Experience Workspaces. Each one closes a gotcha; an LLM that skips them ships a ladder that deploys cleanly and rewards nothing anyone cares about.
| Ask | Why it matters | What a good answer adds |
|---|
| "Which one member behaviour, if it doubled, would make this community worth funding?" | The 16 eventType values ship with defaults that already reward posting (+1) far below answering well (FeedItemYourAnswerMarkedBest +20). If you cannot name the behaviour, you cannot justify deviating from the defaults (api_meta.txt L91694-L91711) | The weighted reputationPointsRules block, with a written reason for every rule that differs from the platform default |
| "Has anyone been active on this site already, and for how long?" | Points start accruing when Reputation is switched on. A site with two years of history gets a leaderboard that inverts the real contribution order on day one | A decision to seed NetworkMember.ReputationPoints, with the seeding query, the members, and who signs it off |
| "What number tells us in 90 days whether this worked, and can we query it today?" | FeedItem "doesn't support aggregate functions in queries" and "You can't filter a feed item on the NetworkScope field" (object_reference.txt L136523, L136183). Half the metrics people ask for cannot be produced the way they assume | The metric set with a queryable source per row — NetworkMember, ChatterActivity, Case.FeedItemId, Topic.TalkingAbout — and a pre-launch baseline reading |
| "What is this site's topic list, and who owns each topic?" | Managed topics are the navigation and the content calendar's index. position takes "a number between 0 and 24. (The maximum amount of navigational or featured topics is 25.)" (api_meta.txt L86768-L86775) | A topic list inside the cap, split Navigational vs Featured, each with a content owner |
| "When a member's question is not answered by the community, who picks it up and where does it land?" | Without a named queue and a trigger condition, unanswered questions are the failure mode that no reputation ladder repairs. Case.FeedItemId is the grounded link back to the question, available "only ... where Question-to-Case is enabled" (object_reference.txt L62410-L62417) | The escalation policy: trigger condition, named queue, owner, and the SOQL that counts escalations |
| "How much of the org's moderation budget is already spent by other sites?" | Keyword lists and moderation rules are capped at 30 each per org, not per site (api_meta.txt L82185, L89486). A recognition programme that assumes a rate rule will freeze point-farmers can find the budget gone | A rule count from the platform owner, and the moderation pointer handed to admin/experience-cloud-moderation before design closes |
| "Who runs the quarterly review, and what are they allowed to change?" | Thresholds calibrated at launch stop discriminating as average activity rises; nobody re-tunes a ladder without a standing mandate | A named reviewer, a cadence, and the list of levers (thresholds, point weights, topic list) they may move without re-approval |
What a proper configuration adds over just turning Reputation on: every rewarded behaviour traces to a goal, every goal has a metric with SOQL that actually runs, the ladder that deploys is the ladder that was designed, and the unanswered question has somewhere to go.
Core Concepts
Reputation on an Experience Cloud site (Network)
Site reputation is three metadata elements on the Network type, and nothing else:
| Element | Type | What it does |
|---|
enableReputation | boolean | "Determines if reputation is calculated and displayed for members." If on and no levels or rules are supplied, "the default values are used" (api_meta.txt L90863-L90873) |
reputationLevels | ReputationLevelDefinitions → level[] | Each level carries an optional label, a required lowerThreshold (double), and optional branding (api_meta.txt L91608-L91651) |
reputationPointsRules | ReputationPointsRules → pointsRule[] | Each rule is an eventType + points pair (api_meta.txt L91654-L91711) |
Two behaviours that decide the design:
label is optional and the fallback is ugly. "If not specified, one of the 10 defaults is used" — Level 1 through Level 10 (api_meta.txt L91633-L91644). Generic labels are what the platform gives you when the strategy step was skipped.- The application computes the top of each band.
lowerThreshold is "the lower value in the range for this reputation level"; ReputationLevel "Represents the name and lower value of the reputation level. The application calculates the upper value." (api_meta.txt L91623, L91647-L91651). You never author an upper bound, which is why an out-of-order or duplicated threshold produces a silently wrong ladder rather than a deploy error.
The 16 documented eventType values, with their platform defaults (api_meta.txt L91675-L91711):
| eventType | Default | eventType | Default |
|---|
FeedItemWriteAPost | +1 | FeedItemShareAPost | +1 |
FeedItemWriteAComment | +1 | FeedItemSomeoneSharesYourPost | +5 |
FeedItemReceiveAComment | +5 | FeedItemPostAQuestion | +1 |
FeedItemLikeSomething | +1 | FeedItemAnswerAQuestion | +5 |
FeedItemReceiveALike | +5 | FeedItemReceiveAnAnswer | +5 |
FeedItemMentionSomeone | +1 | FeedItemMarkAnswerAsBest | +5 |
FeedItemSomeoneMentionsYou | +5 | FeedItemYourAnswerMarkedBest | +20 |
FeedItemEndorseSomeoneForKnowledgeOnATopic | +5 | FeedItemEndorsedForKnowledgeOnATopic | +20 |
The two endorsement events depend on Network.enableKnowledgeable, which "Determines if members can see who's knowledgeable on topics and endorse people for their knowledge on a topic" (api_meta.txt L90848-L90851). Weighting them without enabling the setting rewards an action nobody can perform.
Member point totals live on NetworkMember.ReputationPoints (double, Filter, Sort, Update) — one row per member per site (object_reference.txt L188569-L188576). The ReputationLevel sObject (Label, LevelNumber, ParentId, Threshold) is read-only: its supported calls are describeSObjects(), query(), retrieve() (object_reference.txt L247325-L247382). Read levels from the API; write points.
Topics are the engagement surface, not a tagging afterthought
An engagement strategy without a topic list has nowhere to put a content calendar. ManagedTopics is one file per site (SiteNameA.managedTopics) holding ManagedTopic entries (api_meta.txt L86721-L86779):
| Field | Notes |
|---|
name | The topic name |
managedTopicType | "Navigational" or "Featured" |
topicDescription | "accessible only via the API; there is no corollary in the user interface" |
parentName | "Only navigational topics support parent-child relationships" |
position | "a number between 0 and 24. (The maximum amount of navigational or featured topics is 25.)" |
One discrepancy to know: the ManagedTopics metadata documents managedTopicType as "Navigational" or "Featured" only (api_meta.txt L86747), while the Topic sObject's ManagedTopicType field lists a third value, Content, from API 44.0 onward (object_reference.txt L289110-L289127). Author the metadata file with the two the metadata guide documents.
Three Network switches shape how topics behave for members: enableTopicSuggestions ("Enables topic suggestions when users write posts"), enableTopicAssignmentRules (rules that "automatically assign topics to articles in a site ... admins set up rules to map topics to Salesforce Knowledge data categories"), and enableTalkingAboutStats (api_meta.txt L90893-L90900, L90877-L90882). The last one surfaces Topic.TalkingAbout — "Number of people talking about the topic over the last two months" (object_reference.txt L289145-L289152), which is the only per-topic engagement number the platform hands you without a build.
Ideation (Ideas)
The Ideas feature uses the standard Idea and IdeaTheme objects (object_reference.txt L155401, L156037). Its shape is different from what most engagement plans assume:
- Ideas is an org-level setting, not a per-site one:
IdeasSettings is stored as Ideas.settings with enableIdeas, enableIdeaThemes, enableIdeasReputation and halfLife (api_meta.txt L118310-L118336).
- The container is the zone, not the theme.
Idea.CommunityId is "The zone ID associated with the idea. Once you create an idea, you can't change the zone ID" (object_reference.txt L155493-L155499), while Idea.IdeaThemeID is Nillable (L155551-L155557). A theme is "an invitation to zone members to submit ideas that are focused on a specific topic" (L156038-L156039) — a grouping, not a gate.
Idea.Status is a "Customizable picklist of values used to specify the status of an idea" (object_reference.txt L155685) — the guide names no standard values, so the status set is a design decision you must write down.halfLife "Indicates how quickly old ideas drop in ranking on the Popular Ideas subtab ... A shorter half-life moves older ideas down the page faster" (api_meta.txt L118360-L118365). It is org-wide and it silently governs what members see as "popular".- Ideas-zone reputation is its own system:
IdeaReputationLevel, "You can create up to 25 levels per zone", Name unique and max 50 chars, Threshold "must be unique within the zone ... and must be greater than or equal to zero" (object_reference.txt L155990-L156032).
The Ideas feature is distinct from Q&A. A community question is a FeedItem of Type QuestionPost (object_reference.txt L136368) whose accepted answer is FeedItem.BestCommentId, "The ID of the comment marked as best answer on a question post" (L135862-L135869). Q&A is for support deflection; ideation is for structured product or service input.
Content Contribution Strategy
Content contribution strategy defines who posts what, and when. It must be decided before launch. The three elements are:
- Member roles: Define role tiers — e.g., Lurker (read-only), Contributor (can post), Power User (can post + moderate peer content), Community Manager (full rights). These map to profile + permission set assignments, not to Reputation levels. Nothing on the
ReputationLevel sObject grants access.
- Content ownership: Each content area (how-to articles, product announcements, FAQs, idea themes) needs a named internal owner responsible for keeping it current. Without this, content ages out and engagement drops.
- Member journey mapping: New members need an onboarding path — a welcome post, a "Start Here" article, and a low-barrier first action (e.g., "introduce yourself" post). Without a designed first-touch journey, activation rates stay low.
Measurement, and what the platform will not let you count
Engagement metrics have to be designed against the query surface, not against a wish list:
| Want to know | Query it here | Constraint |
|---|
| Active members, last-touch recency | NetworkMember — ReputationPoints, LastChatterActivityDate ("The last time the member posted or commented in the Experience Cloud site") | Scoped by NetworkId; supports aggregates (object_reference.txt L188353-L188359) |
| Per-member post / comment / like-received volume | ChatterActivity — PostCount, CommentCount, CommentReceivedCount, LikeReceivedCount, InfluenceRawRank, NetworkId | "To query ChatterActivity, you must provide the ParentId" — no org-wide sweep (object_reference.txt L66386-L66388) |
| Questions, best answers, closed threads | FeedItem — Type = 'QuestionPost', BestCommentId, IsClosed | No aggregate functions; no filtering on NetworkScope; direct query needs View All Data (object_reference.txt L136523, L136183, L136504) |
| Topic reach | Topic.TalkingAbout, TopicAssignment | TopicAssignment SOQL wants LIMIT 1100 or a = filter on Id/Entity (object_reference.txt L289283-L289287) |
| Escalation volume and time-to-case | Case.FeedItemId | Only where Question-to-Case is enabled; Case does support aggregates (object_reference.txt L62410-L62417) |
| Moderation load | NetworkActivityAudit — Action, EntityId, EntityCreatedById | Audit of moderation actions, API 30.0+ (object_reference.txt L187427-L187470) |
references/worked-examples.md §6 carries the runnable version of every row.
Common Patterns
Quality-weighted reputation ladder for a peer-support community
When to use: The community's primary goal is peer-to-peer support deflection. Members answer each other's questions, and the business wants to surface trusted advisors.
How it works:
- Set
Network.enableReputation to true and author reputationLevels explicitly — leaving label off gets you Level 1…Level 10.
- Give each level a domain-meaningful
label and a lowerThreshold that is strictly greater than the level before it. The guide's own sample ladder is seven levels at 0 / 51 / 101 / 151 / 201 / 251 / 301 (api_meta.txt L91877-L91943) — start from a real spacing curve, not round numbers.
- Override only the
eventType rules you have a reason to move. FeedItemYourAnswerMarkedBest already defaults to +20 against FeedItemWriteAPost at +1; if answering is the goal, the platform default is already close and the interesting decision is whether to lower posting further.
- Run
scripts/check_community_engagement_strategy.py over both the strategy YAML and the Network file so the deployed ladder and the designed ladder cannot drift.
Why not a flat point system: A flat system (one action type = one point) rewards volume of posts with no quality signal. Weighting best-answer actions higher encourages members to provide complete, useful answers rather than short replies that farm points.
Topic-indexed content calendar
When to use: A community is technically live and quiet, and the content plan is a list of blog-style ideas with no anchor in the site's navigation.
How it works:
- Take the site's
ManagedTopics file as the index. Every calendar item names one topic that exists in that file.
- Split the topic list deliberately: Navigational topics carry the menu and support parent/child nesting; Featured topics carry the home-page thumbnails and do not nest.
- Keep the combined list inside the documented 25 and leave headroom —
position accepts 0-24, so a full list has no room for the next quarter's topic.
- Give each calendar item an owner, a target date, and one of the metric rows from
references/worked-examples.md §6 that it is supposed to move.
- Where a topic maps to published Knowledge, consider
enableTopicAssignmentRules and hand the data-category mapping to admin/knowledge-base-administration.
Why topics rather than a content list: A calendar item with no topic has no navigation path to it, no TopicAssignment row, and therefore no Topic.TalkingAbout reading afterwards. The topic is what makes the item measurable.
Product ideation portal with a defined status workflow
When to use: A product or operations team wants structured customer input through a community channel, with clear feedback on what happens to submitted ideas.
How it works:
- Confirm the org-level
IdeasSettings (enableIdeas, and enableIdeaThemes if themes are used) and the zone the site's ideas belong to.
- Decide and document the
Idea.Status picklist values — the platform ships a customizable picklist and no opinion.
- Create themes per product area for grouping, knowing that ideas can exist without one.
- Assign an internal product manager as the owner of each theme; their job is to update statuses on a stated cadence.
- Announce status updates in the idea's comment thread so voters see progress.
- Check
halfLife before blaming the ranking: it is an org-wide dial on how fast old ideas fall down Popular Ideas.
Why an explicit status workflow matters: Ideas with no status movement for 90+ days communicate to members that feedback goes unread. This is the top cause of ideation disengagement. An "Under Review" update — even without a decision — signals responsiveness.
Decision Guidance
| Situation | Recommended Approach | Reason |
|---|
| Community goal is support deflection | Weight the answer-side eventType rules and leave posting at or below the default | FeedItemYourAnswerMarkedBest (+20) vs FeedItemWriteAPost (+1) already encodes quality over volume |
| Community goal is product input | Prioritize ideation with a written Idea.Status set and named theme owners | The status picklist is customizable with no standard values; undocumented means undecided |
| Community goal is content publishing (help center) | Prioritize the contribution strategy: content owners and author roles before contribution rights | Prevents content sprawl and outdated articles |
| The site has an active member base and Reputation is off | Design the ladder and the NetworkMember.ReputationPoints seeding pass together | Points accrue forward only; the field is updateable via the API |
| Someone asks for "posts per member per month, all members" | Redesign the metric onto NetworkMember / ChatterActivity per member | FeedItem supports no aggregates and cannot be filtered by NetworkScope |
| Org has multiple Experience Cloud sites | Configure reputation per site; NetworkMember is per member per NetworkId | Levels, rules and point totals all hang off one site's Network |
| The topic list is already at 20+ entries | Retire before adding, and prefer Featured for campaign topics | Navigational and featured topics share a documented maximum of 25 |
| Someone proposes auto-promoting high-tier members to moderator | Route the permission decision to admin/experience-cloud-moderation | ReputationLevel is query-only and carries no permission field |
Recommended Workflow
- Fill in the Questions table above with the sponsor, then start
templates/community-engagement-strategy-template.md. Sections 1-2 (site, pillars in scope) and section 12 (metrics) are the parts that decide everything downstream; the ladder is easier than the goals.
- Draft the ladder against
references/worked-examples.md §3. Name every level, set lowerThreshold strictly increasing, and write the reason beside each eventType whose points differ from the platform default in ## Core Concepts. Confirm enableKnowledgeable before weighting either endorsement event.
- Index the content calendar on the site's managed topics (
references/worked-examples.md §4). One topic per calendar item, one owner per item, list length inside 25.
- Write the metric set and the escalation policy before configuring anything (
references/worked-examples.md §6 and §5). Every goal gets one metric, one SOQL source, and a target. Every metric must survive the constraints in the measurement table above — that is the step that catches SELECT COUNT() FROM FeedItem.
- Emit the engagement-strategy YAML and the
Network reputation fragment using references/worked-examples.md §8 and §7 as the shape, and cross-check the moderation half against admin/experience-cloud-moderation before assuming a rate rule is available.
- Run
python3 scripts/check_community_engagement_strategy.py --manifest-dir <dir> (or --file <strategy.yaml> --manifest-dir <metadata dir>). It fails on non-monotonic or duplicated thresholds, calendar items pointing at topics that do not exist, goals with no queryable metric, a moderation policy with no escalation queue, and a Network file whose levels do not match the ladder.
- Book the quarterly review using
references/worked-examples.md §9 and record the reviewer in template section 14.
Review Checklist
Run through these before marking work in this area complete:
Salesforce-Specific Gotchas
Short list; the full form of each — what happens, when, how to avoid — is in references/gotchas.md.
- Points accrue forward only; an existing member base starts at zero.
label is optional, so an omitted label deploys as Level 1…Level 10.- Only
lowerThreshold is authored — the platform derives the band's top.
ReputationLevel is query-only and grants no permission at any tier.- Ideas hang off a zone;
Idea.IdeaThemeID is nillable, so a theme is optional.
- Site reputation and Ideas-zone reputation are two systems with different caps.
FeedItem supports no aggregates and cannot be filtered on NetworkScope.ChatterActivity cannot be queried without a ParentId, and lurkers have no row.- Renaming a
Topic is limited to spacing and capitalization.
- Pre-moderation makes
FeedItem.CommentCount lag the real comment count.
- Moderation rules and keyword lists are capped at 30 each per org, not per site.
Output Artifacts
| Artifact | Description |
|---|
| Reputation ladder | Named levels with monotonic unique lowerThreshold values, plus the weighted eventType table and the reason for each deviation |
Network reputation fragment | Deployable enableReputation / reputationLevels / reputationPointsRules block matching the ladder |
| Topic-indexed content calendar | Calendar items, each naming an existing managed topic, an owner, a date and the metric it moves |
| Engagement metric set | One row per goal: metric, SOQL source, baseline, target, owner |
| Health dashboard spec | The report/dashboard components each metric feeds, and their refresh cadence |
| Moderation + escalation policy | Trigger conditions, the named escalation queue, and the pointer to the moderation skill for rules |
| Content ownership map | Table mapping each content area to an internal owner, review cadence, and content type |
| Member role matrix | Table mapping member roles to the profile/permission set that backs them |
| Quarterly review checklist | Standing agenda, named reviewer, and the levers they may move without re-approval |
Reference Files
| File | Read it when |
|---|
references/worked-examples.md | Filling in the strategy — Acme's customer community six months after launch, worked end to end: personas and goals, the topic-indexed content calendar, the recognition ladder with its Network XML, the moderation and escalation policy, six metrics with runnable SOQL, the dashboard spec, the quarterly review, and the YAML the checker lints |
references/gotchas.md | The ladder deployed but ranks people wrongly, a metric query errors, a topic will not rename, or reputation and permissions were assumed to be linked — eleven platform behaviours behind those symptoms |
references/examples.md | Working a real engagement problem end to end: the point-farming leaderboard, the black-hole ideation portal, and the unseeded-launch anti-pattern |
references/llm-anti-patterns.md | Reviewing AI-generated community advice, especially generic tier names and metric plans built on SELECT COUNT() FROM FeedItem |
references/well-architected.md | Framing the ladder-depth, ideation-breadth and open-contribution tradeoffs, and locating the source behind each claim |
templates/community-engagement-strategy-template.md | Workflow step 1, and again at review time as the one-page record of every decision |
scripts/check_community_engagement_strategy.py | Workflow step 6, before the strategy leaves your hands and again before the Network deploys |
Related Skills
admin/experience-cloud-moderation — Owns KeywordList and ModerationRule, the moderation queue, and the Moderate Experiences Feeds permission behind the escalation policy this skill writes.admin/experience-cloud-site-setup — Owns the Network, CustomSite, NavigationMenu and ExperienceBundle deploy set that this skill's reputation fragment lands inside.admin/self-service-design — Owns the deflection journeys, article visibility matrix and case exposure model that the peer-support layer sits on top of.admin/knowledge-base-administration — Owns data categories, record types and the publishing workflow that enableTopicAssignmentRules maps topics onto.admin/chatter-group-governance — Owns the group lifecycle, visibility and ownership-transfer policy behind any group-based contribution model.admin/chatter-notification-tuning — Owns the digest and notification volume that decides whether recognition is actually seen.data/community-analytics-data — Owns login, page-view and post-launch engagement reporting once these metrics have a baseline.