Working in ATS

Daily Operating Model

ATS 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: Publish a job and receive applications

1. Open Jobs and create a job posting with title, department, location, openings, and description.
2. Choose the recruitment pipeline and initial application stage.
3. Attach global or job-specific application questions.
4. Preview the careers page and embedded job apply route.
5. Publish or open the posting when content and permissions are approved.
6. Candidates apply through the careers or embed routes.
7. Recruiters review incoming applications from Applications.
8. Use workflow notifications for new applications or high-priority roles.

Flow 2: Move an applicant through the pipeline

1. Open Applications or Pipeline and filter by job posting.
2. Review candidate details, application answers, resume, and notes.
3. Move the application to the next stage when screening is complete.
4. Add notes or feedback for the hiring team.
5. Schedule interviews and assign interviewers.
6. Record interview outcome and feedback.
7. Shortlist, reject, or advance the application based on stage rules.
8. Keep stage history clean so reports can show conversion and aging.

Flow 3: Schedule interviews and capture feedback

1. Open the candidate application and create an interview record.
2. Set interview type, date, time, panel, and meeting instructions.
3. Notify interviewers through tasks, calendar integration, or workflow notifications.
4. Interviewers submit feedback using the configured evaluation process.
5. Recruiter reviews feedback and resolves missing or conflicting input.
6. Advance, reject, or schedule the next round.
7. Record no-show or cancellation when the meeting does not happen.
8. Use interview reports to spot scheduling bottlenecks.

Flow 4: Send an offer and hand off to HCM

1. Create an offer for the selected application.
2. Confirm compensation, start date, role, department, and approval requirements.
3. Send the offer after internal approval.
4. Track accepted, rejected, declined, or withdrawn status.
5. When accepted, coordinate employee creation in HCM.
6. Copy candidate details into the employee record or onboarding workflow.
7. Close remaining applications or postings if the role is filled.
8. Report on time-to-offer and offer acceptance rate.

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/ats for namespace and intent details.