Profiles setup

Settings Routes

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

• /profiles/settings/[...page]
• /settings/users/[...page]
• /settings/objects
• /settings/pages/[...page]

Prerequisites

• Define the profile types and lifecycle states needed by the tenant.
• Decide which data belongs on profiles versus Base objects or contacts.
• Create sections and questions before collecting data at scale.
• Grant profile admins, editors, and viewers according to sensitivity.
• Decide whether profiles are internal-only or exposed through pages and portals.
• Prepare deduplication and import rules for existing contact lists.

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/profiles before handing credentials to an integration.

Recommended First-Time Checklist

1. Open Launchpad -> Profiles 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/profiles/models.py.
• Frontend screens and settings were checked in Base app profile routes in packages/antly-app or the Base app routes listed above.
• Automation and API details should be checked against /reference/profiles 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.