Customer Portal & Public Surfaces
Careers pages
Publish ATS job listings and embedded application pages.
Careers pages
Careers pages covers ATS public careers site, published job postings, embedded job lists, application forms, candidate intake, and recruiting pipelines. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: ATS public careers site, published job postings, embedded job lists, application forms, candidate intake, and recruiting pipelines.
- Where users start: ATS careers settings live at
/ats/settings/careers-site; public careers pages use/ats/careers; embedded job lists use/ats/embed/jobs. - Where administrators configure it: Recruiters manage jobs at
/ats/jobs, applications at/ats/applications, pipelines at/ats/applications/pipeline, and fields at/ats/settings/application-fields. - Runtime/detail surface: Candidates apply from public or embedded surfaces; recruiters process submissions in ATS.
- Platform connections: Careers pages connect ATS job postings, application fields, files, candidate records, pipeline stages, notifications, and reports.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | ATS careers settings live at /ats/settings/careers-site; public careers pages use /ats/careers; embedded job lists use /ats/embed/jobs. | Day-to-day work and review. |
| Configuration | Recruiters manage jobs at /ats/jobs, applications at /ats/applications, pipelines at /ats/applications/pipeline, and fields at /ats/settings/application-fields. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Candidates apply from public or embedded surfaces; recruiters process submissions in ATS. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: ATS careers settings live at
/ats/settings/careers-site; public careers pages use/ats/careers; embedded job lists use/ats/embed/jobs. - Review the configuration route and permissions before changing live behaviour: Recruiters manage jobs at
/ats/jobs, applications at/ats/applications, pipelines at/ats/applications/pipeline, and fields at/ats/settings/application-fields. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Careers site, Job posting, and Application fields first because they shape the rest of the rollout.
- Add Pipeline and Embedded jobs only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Candidates apply from public or embedded surfaces; recruiters process submissions in ATS.
- Check downstream connections after saving: Careers pages connect ATS job postings, application fields, files, candidate records, pipeline stages, notifications, and reports.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Careers site | Candidates need a public job board | Configure at /ats/settings/careers-site. |
| Job posting | A role should accept applications | Create at /ats/jobs/add. |
| Application fields | Candidate forms need custom questions | Use /ats/settings/application-fields. |
| Pipeline | Recruiters track stages | Route: /ats/applications/pipeline. |
| Embedded jobs | External website should show openings | Use /ats/embed/jobs. |
| Candidate/application | Recruiters review submissions | Routes: /ats/candidates and /ats/applications. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Careers site and Job posting.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.