Forum setup

Settings Routes

Use these routes from Launchpad -> Forum or the relevant settings navigation. Route availability still depends on tenant permissions and feature access.

• /forum/settings/[...page]
• /settings/users/[...page]
• /settings/pages/[...page]

Prerequisites

• Create categories that reflect how users ask questions.
• Define moderation policy for pinning, locking, closing, featuring, and archiving.
• Assign moderators and escalation owners.
• Decide which forum areas are internal, tenant-only, or public.
• Prepare notification and subscription expectations.
• Link forum categories from portals or pages only after permissions are verified.

Permissions To Plan

• Separate administrators who can change settings from operators who can create and update daily records.
• Give read-only access to reporting audiences instead of granting broad edit permissions.
• Protect delete, void, post, refund, close, publish, approve, and status-changing actions behind trusted roles.
• Review permissions for imported records, API keys, and workflow service users as carefully as UI users.
• Check whether self-service users should see only their own records, their team records, or all tenant records.
• Keep public or embedded routes limited to records intended for public exposure.
• Use Base page permissions when a custom workspace should expose only part of the module.
• Confirm reference/API access in /reference/forum before handing credentials to an integration.

Recommended First-Time Checklist

1. Open Launchpad -> Forum and confirm the module loads for an administrator.
2. Create or confirm the global tenant data the module depends on: users, teams, locations, holidays, departments, currencies, or objects as applicable.
3. Visit each settings route listed above and decide which settings are required before go-live.
4. Create one realistic configuration record for each required setup area.
5. Create one realistic operational record and move it through its expected lifecycle.
6. Confirm list, detail, create, edit, approval, and report views behave correctly for administrator and normal user roles.
7. Configure at least one workflow notification or task for an important exception.
8. Check that reports show the pilot records with the expected filters and dimensions.
9. Check that JQL/API access is limited to the namespaces the integration or script actually needs.
10. Document who owns configuration, daily operation, reporting, and exception resolution.
11. Clean up pilot data or mark it clearly before importing production data.
12. Review audit/history surfaces after key actions so compliance users know where to look.

Validation Before Go-Live

• A normal operator can create and update the records they own without seeing restricted settings.
• An approver can approve or reject without gaining unnecessary administrator access.
• A reporting user can read reports without changing source records.
• A workflow can receive the expected payload and create a task, notification, approval, or related record.
• A failed or rejected record remains visible with enough context to resolve it.
• The module reference page matches the namespaces and intents planned for integrations.
• Public, embedded, or portal routes expose only intentional data.
• Imports, if used, preserve tenant ownership, status, owner, dates, and required relationships.
• The team knows which records must never be deleted because they support audit or historical reporting.
• Owners have a recurring review rhythm for settings and permissions.

Implementation Notes

• Backend records come from src/forum/models.py.
• Frontend screens and settings were checked in Base app forum routes in packages/antly-app or the Base app routes listed above.
• Automation and API details should be checked against /reference/forum during implementation.
• Keep configuration changes small at first; prove one complete lifecycle before importing or enabling broad access.
• Use workflows for repeatable approvals and notifications rather than relying on manual reminders.
• Use tasks for exceptions that need named ownership.
• Use reports to confirm the setup is producing useful operational data.
• Review permissions again after the first production week, when real usage patterns are visible.

Ongoing Administration

• Review settings after the first production week.
• Review role access whenever teams or reporting lines change.
• Review workflow failures before each operating cycle closes.
• Review integration keys and API permissions quarterly.
• Review reports with the users who depend on them.
• Review archived, cancelled, or rejected records for cleanup policy.
• Review public, embedded, or portal exposure after every route change.
• Review the reference page before adding new automation.