Working in Forum

Daily Operating Model

Forum works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Create forum structure

1. Open Forum Settings and create categories.
2. Define category names, descriptions, order, and audience.
3. Assign moderators for each category.
4. Set public or internal exposure according to policy.
5. Seed announcement or FAQ topics where helpful.
6. Test topic creation as a normal user.
7. Review subscription and notification behavior.
8. Publish links from pages or portal navigation.

Flow 2: Start and manage a topic

1. User opens Forum and creates a topic in the correct category.
2. Other users reply with posts and reactions.
3. Original poster or moderator clarifies title and category if needed.
4. Users subscribe to follow updates.
5. Moderator pins or features high-value topics.
6. Close or lock the topic when the discussion is resolved or unsafe.
7. Archive stale topics according to retention policy.
8. Use reputation and engagement signals to identify helpful contributors.

Flow 3: Moderate content

1. Moderator reviews reported, off-topic, duplicate, or unsafe content.
2. Move the topic to the right category when it is misplaced.
3. Edit, delete, lock, close, pin, feature, or archive through permitted actions.
4. Record the moderation reason.
5. Use ModerationHistory to audit actions.
6. Create tasks for legal, support, or security escalation when required.
7. Notify participants when moderation changes their topic.
8. Review repeat issues and update category guidance.

Flow 4: Turn discussions into knowledge

1. Identify repeated questions or high-quality answers.
2. Create or update a Knowledge Base article from the accepted guidance.
3. Link the article back into the forum topic.
4. Close the topic when the canonical answer is published.
5. Use reports to find unanswered or stale discussions.
6. Create workflow reminders for topics with no accepted response.
7. Reward helpful contributors through reputation signals.
8. Use forum trends to guide product or support priorities.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/forum for namespace and intent details.