Configuring Requisition Templates, Status Flows, and Role-Based Permissions
Covers how consultants design and configure job requisition templates, candidate status flows, and role-based permissions to control who can view and act on requisitions and applications.
Explanation
Once the foundational data model is understood, intermediate configuration work centers on three interconnected areas: requisition templates, status flows, and role-based permissions (RBP). These determine what fields exist on a requisition, how a candidate moves through the hiring pipeline, and who can see or act on that data. Requisition templates define the field layout, business rules, and approval workflow associated with a category of job (for example, a template for hourly retail positions versus one for corporate exempt roles). Templates are typically built from a base requisition object configuration that includes standard fields (job title, department, hiring manager, recruiter) plus custom fields the customer needs (cost center, union code, safety-sensitive flag). Consultants must decide how many templates are needed: too many creates maintenance overhead, too few forces awkward conditional logic. A common approach is to group templates by hiring pattern rather than by every possible job title. Status flows represent the configurable stages an application moves through, such as New, Under Review, Interview, Offer, Background Check, and Hired, along with disqualification reasons. Each status can trigger specific behavior: enabling interview scheduling actions, releasing offer letter generation, or restricting which user roles can move the application further. Status flow design must reflect the customer's actual hiring process rather than a generic template, because mismatched flows cause recruiters to work around the system rather than through it, undermining reporting accuracy. Role-based permissions in Recruiting control visibility and actions at multiple levels: who can create requisitions, who can view specific requisition fields, who can see candidate personal data, and who can move an application between statuses. Permission groups are typically built around roles such as Recruiter, Hiring Manager, Recruiting Coordinator, and HR Business Partner, with target populations often scoped by department, division, or location using dynamic groups. A frequent design decision is whether hiring managers should see all applicants or only those recruiters have advanced to interview stage, which has direct implications for candidate experience and data privacy. Integration with Employee Central matters here too: requisition data often pulls organizational structure (department, division, location) directly from Employee Central's foundation objects, so misalignment between Recruiting configuration and Employee Central's org structure causes requisition creation errors or incorrect approval routing. Similarly, permission groups in Recruiting should be reconciled with Employee Central RBP groups where the same population is referenced, to avoid maintaining duplicate, drifting definitions. Troubleshooting at this level typically involves diagnosing why a user cannot see a requisition or application (usually a permission group or target population mismatch), why an approval workflow is stuck (missing approver setup or organizational data gap), or why a status transition button is missing (status flow configuration or permission restriction). Systematic diagnosis means checking, in order: the user's assigned permission role, the target population definition, the requisition's organizational attributes, and the status flow rules for that requisition template.
Real project scenario
During a UAT cycle for a manufacturing client, hiring managers reported they could not view candidates who had applied to their open requisitions. Investigation showed the RBP target population for the Hiring Manager role was scoped by legal entity, but a recent Employee Central reorganization had moved several cost centers to a new legal entity without updating the corresponding Recruiting permission group, causing a silent visibility gap that required both Recruiting and Employee Central teams to jointly resolve.
Common mistakes
• Creating a separate requisition template for every job title instead of grouping by hiring pattern • Designing status flows that do not match the customer's real hiring process, causing recruiter workarounds • Scoping RBP target populations independently in Recruiting without reconciling with Employee Central org structure • Granting hiring managers full applicant visibility by default without confirming data privacy requirements • Failing to test permission changes against multiple roles (recruiter, hiring manager, coordinator) before go-live
Best practices
• Group requisition templates by hiring pattern rather than by individual job title to reduce maintenance overhead • Validate status flow design against the customer's actual recruiter workflow during configuration workshops, not just documentation • Reconcile Recruiting RBP target populations with Employee Central organizational structure whenever foundation objects change • Document which roles can view sensitive candidate data and confirm alignment with data privacy or works council requirements • Test permission and status flow changes with representative users from each role before promoting to production
Interview angle
A common interview probe is asking how you would troubleshoot a scenario where a hiring manager cannot see an applicant, testing whether you know to check permission groups, target populations, and organizational data alignment rather than assuming a system defect. Explaining the layered diagnostic approach signals production support experience.