ADP Workforce Now can hold some of the most sensitive information an employer manages. Payroll data, bank details, tax identifiers, compensation history, benefits elections, dependent information, and employee records can all sit close together inside the same HCM environment. That makes access design a business control, not a setup task that should be left unchanged after implementation.
The hard part is deciding where access should stop. Payroll needs enough information to calculate pay. HR may need broad employee records without needing every payroll function. Managers need information about their teams, but that doesn’t mean they should see every salary or sensitive identifier. Finance may need payroll totals while having no reason to edit an employee record. Good ADP Workforce Now security roles reflect these differences.
This checklist explains how to decide who should see what, where view access should differ from edit access, how People Access and Payroll Processing Access fit into the decision, and what to review before an access change goes live. The goal is a permission model that matches current work and can be explained during an internal review.
TL;DR
ADP Workforce Now access should follow the work a person performs, the employee population they support, and the sensitivity of the data they need. Review menu access, People Access, Payroll Processing Access, view versus edit rights, and sensitive-field visibility as separate decisions. Employees should normally see their own records. Managers should normally see defined team information. HR, payroll, benefits, finance, recruiting, and security administrators should receive only the functions and worker populations required for their duties. Integration accounts need the same review because they can expose large amounts of data without an interactive user. Recheck access after role changes, terminations, module changes, and major organizational moves.
What ADP Workforce Now security roles actually control
ADP Workforce Now security roles shouldn’t be treated as simple job-title labels. A useful security design asks several different questions at once: which functions can the person reach, which employees can the person reach, which actions can the person perform, and which sensitive values can the person reveal. ADP currently lists roles-based security as part of Workforce Now digital recordkeeping, and its Workforce Now options also describe secure employee records and auditing functions. That means access can affect both daily work and the organization’s ability to explain who had access to data.
The most important mistake to avoid is assuming that access to a module automatically defines safe access inside that module. A manager may need timecard approval without needing broad compensation data. A benefits administrator may need dependent information without needing payroll-processing rights. A payroll practitioner may need pay groups without needing talent records. ADP Workforce Now permissions work best when those boundaries are decided separately.
A practical ADP security role checklist starts with 4 control layers. First, decide which menus and functions are required. Second, define the worker population the user may access. Third, separate view rights from edit rights. Fourth, decide whether sensitive values should remain masked. Those layers give you a clearer answer than asking whether someone should simply be an “HR user” or “payroll user.” ADP Workforce Now security roles should be tested as combinations of these controls rather than treated as fixed labels.
Set access boundaries from current work
Build the permission map from current duties and worker populations. NIST’s least privilege definition supports limiting access to what a user needs for assigned work. In Workforce Now, turn that principle into a specific record of the function, worker population, and action each permission supports. This keeps ADP Workforce Now permissions tied to current work instead of a broad department label.
Where one user can prepare and approve the same sensitive transaction, review that approval path as part of the role matrix. NIST’s access-control guidance calls for identifying duties that should be separated and setting access accordingly. If staffing requires combined duties, record the exception in the checklist and keep People Access or Payroll Processing Access limited to the smallest population that still lets the person do the work.
Who should see what: recommended role matrix
The matrix below is a starting point for reviewing ADP Workforce Now security roles. It isn’t an ADP-prescribed template. Your organization may need different access because of payroll structure, purchased modules, legal requirements, or staffing. The important point is to document why each role receives access and where that access stops.
| Role | Usually Needs To See | Usually Needs To Do | Common Restrictions To Review |
| Employee | Own pay, tax, time, benefits, personal information | Self-service changes and requests allowed by policy | Other employees, security setup, payroll processing |
| Manager | Direct reports, time, schedules, selected job and performance data | Approvals and manager actions for assigned staff | Tax IDs, bank data, unrelated employees, broad payroll functions |
| HR Generalist | Employee records, job data, status, assigned HR workflows | Maintain HR information for supported populations | Payroll processing, security administration, unneeded bank details |
| Payroll Processor | Pay data, taxes, deductions, time inputs, assigned payroll populations | Prepare and correct payroll within assigned scope | Unrelated HR modules, broad security rights, unrelated pay groups |
| Benefits Administrator | Eligibility, elections, dependents, plan information | Maintain benefits data and enrollment workflows | Payroll processing, broad compensation rights, bank information |
| Compensation Administrator | Salary, ranges, compensation history, planning information | Manage approved compensation activity | Payroll processing and unrelated personal information |
| Recruiter | Candidate, requisition, offer, and hiring information | Recruiting and approved hiring steps | Employee payroll data, tax IDs, bank data |
| Finance | Payroll totals, labor-cost reports, GL outputs | Reconcile and report financial results | Employee record editing and unnecessary personal identifiers |
| Security Administrator | User access and security configuration | Grant, change, and remove access | Routine business transactions where separation is practical |
| Integration Account | Fields and populations required by the integration | Read or write only what the connection requires | Interactive use, unrelated fields, broad employee populations |
This matrix should be converted into named access decisions in your own ADP security role checklist. “Manager” is still too broad if some managers handle compensation reviews and others don’t. “HR” is too broad if one HRBP supports 300 employees and another supports a separate region. The matrix gives the expected boundary, then ADP Workforce Now permissions should reflect the actual assignment.
Employee and manager access
Employees normally need access to their own information and approved self-service functions. ADP’s current employee self-service guidance describes common employee actions such as viewing pay, requesting time off, enrolling in benefits, and updating contact information. The same source describes manager self-service as controlled access to team information and actions such as PTO approval, schedule changes, timecard review, and performance information.
That distinction matters because manager access can spread farther than intended. A manager may need team schedules and job information every day, but salary history might be needed only during a compensation cycle. Tax identifiers and bank details are rarely needed for ordinary supervisory work. If a manager can see data unrelated to team management, the reason should be documented rather than assumed.
Employee access
Employee access should normally follow self-service. Users can see their own pay statements, tax documents, time information, benefits, and personal details to the extent your setup allows. ADP’s mobile app capabilities include pay and tax information for employees and manager approvals for timecards, schedules, and requests. That supports a clean boundary between personal self-service and supervisory work.
Manager access
Manager access should follow a defined employee population, commonly direct and indirect reports based on your organizational design. ADP Workforce Now People Access is important here because a manager who can reach an unrelated population may see more than the manager role intended. Pay visibility needs an explicit decision. ADP Workforce Now security roles for managers should reflect whether compensation work is actually part of the manager’s job. If managers participate in merit planning, selected compensation fields may be justified. If they don’t, broad pay access creates exposure without helping them perform their role.
A manager should also have edit rights only where manager action is expected. Approving time is different from changing an employee’s tax setup. Updating a schedule is different from changing a bank account. The cleanest design makes those differences visible in the permission map.
HR and benefits access
HR often needs broad employee information, but “HR needs everything” is a weak security rule. ADP’s current HR Management features cover employee records, hiring and separation, job information, salary structures, workflow, reporting, and other lifecycle activity. That breadth makes HR one of the roles that needs careful scope decisions rather than automatic full access.
An HR generalist may need demographics, job history, employment status, manager relationships, leave information, and compensation visibility for the employees they support. The same person may have no operational reason to process payroll or reveal a full bank account. If HR staff are divided by business unit, region, or legal entity, ADP Workforce Now People Access should follow that design instead of giving every HR practitioner the full workforce by default.
Benefits access is narrower in purpose but still sensitive. ADP’s current benefits administration features include employee and dependent enrollments, eligibility reporting, plan information, and enrollment activity. Benefits administrators may therefore need dependent and beneficiary data that other HR users don’t need, while still having no reason to process payroll.
The ADP security role checklist for HR and benefits should ask whether the user needs salary visibility, compensation edit rights, dependent information, leave data, tax identifiers, payroll menus, and access to every employee population. A yes to one doesn’t require a yes to the others. ADP Workforce Now security roles should reflect those differences even when the people involved report to the same HR leader.
Payroll and finance access
Payroll processors need deep payroll access, but they don’t automatically need broad authority across the rest of Workforce Now. ADP’s current payroll feature list includes taxes, deductions, general ledger output, payroll reports, employee changes, and earnings review. A payroll role may therefore require sensitive information, but that information should still be tied to the payroll populations the person is assigned to support.
ADP Payroll Processing Access should be reviewed by company code, pay group, or the relevant payroll population available in your configuration. A practitioner who processes only one payroll group shouldn’t receive broader processing rights merely because the user can view other employees. People Access and Payroll Processing Access solve different problems, so they should be reviewed as separate controls.
Payroll processor versus reviewer
Where staffing permits, separate payroll preparation from final review or approval. ADP Payroll Processing Access should support that split rather than giving every payroll user the same processing scope. One user may need to enter changes and clear exceptions. Another may need totals, variance reports, or approval rights without changing the underlying data. The exact workflow depends on your organization, but the permission model should make it difficult for unnecessary combinations of rights to accumulate unnoticed.
Finance access
Finance typically needs payroll results more than payroll administration. General ledger files, labor-cost reports, departmental totals, and reconciliation outputs can support finance work without granting the ability to change employee demographic or banking data. If a finance user needs detail for a specific investigation, consider whether view-only access to a report can meet the need instead of persistent edit access to employee records.
This is an area where ADP Workforce Now permissions should be built around outputs. ADP Workforce Now security roles for finance should focus on the reports and results finance needs rather than on broad employee administration. Ask what finance must reconcile, which employee-level fields are truly required, and whether access can remain read-only. That keeps payroll administration with payroll while still giving finance enough information to close the books.
Compensation and recruiting access
Compensation data needs its own permission decision because it crosses HR, manager, and payroll work. ADP’s compensation features describe user visibility rules that can control which employees and compensation elements a user sees. Managers involved in pay planning may need salaries, ranges, historical awards, or planning worksheets for their staff without needing payroll-processing rights.
Compensation administrators usually need wider pay visibility than line managers. Even then, edit rights should match the compensation process. The ability to plan or recommend an increase isn’t necessarily the same as the ability to alter payroll setup. Keep planning access, approved changes, and payroll processing distinct where your configuration and workflow allow it.
Recruiting creates a different boundary. Recruiters may need candidate records, requisitions, offers, hiring steps, and selected onboarding information. They normally don’t need ongoing access to employee tax setup, direct deposit, or unrelated salary history after a candidate becomes an employee. If recruiting staff help with onboarding, define the handoff point between candidate data and employee administration so access doesn’t remain broader than the recruiting role.
The ADP security role checklist should also account for temporary compensation-cycle access and recruiting projects. Time-limited access is safer than leaving higher-level rights in place because the person may need them again next year.
Security administrators and privileged accounts
Security administration is one of the most sensitive forms of access because it can change everyone else’s access. NIST’s current guidance for privileged accounts says privileged accounts should be restricted to defined personnel or roles. In practice, the group that can grant ADP Workforce Now permissions should be small enough that ownership is clear and changes can be reviewed.
A security administrator doesn’t automatically need to perform payroll, benefits, recruiting, or compensation transactions. Combining security administration with routine business processing may be unavoidable in a small team, but the overlap should be known and documented. Where duties can be split, keep access administration separate from the transactions that the same access controls protect.
Integration administration also needs its own role boundaries. ADP’s current API Central controls also show role separation for project, certificate, and member administration in integration management. The broader lesson applies to Workforce Now security roles: privileged access should have a defined purpose, a named owner, and a review process.
Use named administrator accounts rather than shared identities where possible. Review who can create users, change profiles, grant sensitive permissions, or alter integration access. A person who no longer performs security administration shouldn’t retain privileged rights as a backup convenience.
People Access and Payroll Processing Access
People Access answers a basic question: which workers can this practitioner reach? ADP’s practitioner permission guide shows People Access and Payroll Processing Access as separate permission areas in a Workforce Now sandbox. The example grants broad view and edit rights for testing, but production access should be narrowed to the population required for the user’s actual job.
ADP Workforce Now People Access should be reviewed whenever a user’s organizational scope changes. A manager who moved departments may still have an old population. An HRBP may inherit another region. A payroll specialist may gain temporary coverage during an absence and keep it afterward. These are common ways access expands without a deliberate security decision.
Connected applications inherit population boundaries too. The Worker Management API guide also notes that People Access affects worker data available through integrations. That matters because the same population boundary can protect both interactive users and connected applications. If an integration profile can reach every worker, confirm that the connected system really needs every worker.
ADP Payroll Processing Access should receive a parallel review. The practitioner may need view rights for a broad HR population but payroll-processing rights for a smaller group. Document both scopes. A good ADP security role checklist records function and population together so reviewers don’t mistake broad People Access for permission to process every payroll.
Sensitive personal information and masking
Sensitive-field access deserves its own review because a user can have a valid reason to reach an employee record without needing every value inside it. ADP’s Dependents API guide documents sensitive field masking for the Marketplace Data Connector profile, including Tax ID and birth date masking and connector-specific reveal and edit settings. Those instructions apply to that connector profile, so don’t assume the same labels or controls apply identically to every practitioner security profile. Use the example to identify fields that may need separate treatment, then verify the controls available in your own Workforce Now setup.
At minimum, review access to Social Security numbers or other tax identifiers, birth dates, bank account information, routing numbers, compensation, tax withholding, deductions, garnishments, dependent information, and personal contact data. Your purchased modules and company policies may add more categories. The question isn’t whether the user can see the employee. The question is whether the user needs each sensitive field to complete assigned work.
A simple field decision model is effective:
· No access when the role doesn’t need the field.
· Masked or view-only access when the role needs confirmation without full reveal or editing.
· Reveal or edit rights only when the job requires the full value or a change to it.
Don’t assume that view access should imply edit access. A payroll reviewer may need to see an earning but not change it. An HR partner may need salary visibility but not bank details. A manager may need an employee’s work phone but not personal tax information. ADP Workforce Now security roles become easier to defend when these field-level decisions are explicit.
Integration and service account access
Integration accounts need the same scrutiny as human users. They can read or write data at high volume, and their access may continue even when no one is actively looking at the account. ADP’s role-based document controls illustrate the broader Workforce Now model in which access can be controlled by role for managers, employees, and HR staff. Connected systems should follow the same need-to-know idea.
Start by identifying every active integration and its owner. Record what data it reads, what it writes, which worker population it can reach, and whether it needs unmasked sensitive fields. If the integration only sends job and organization data to a planning tool, bank information has no reason to be available. If it supports payroll, the required scope may be different.
Service accounts also need lifecycle controls. Remove connections that are no longer used. Revisit access when an integration changes purpose or vendor. Review certificate and credential ownership. If a connection was created for a project that ended, don’t assume the account is harmless because no employee signs in to it.
ADP Workforce Now permissions for integrations should be documented beside human access, not in a separate forgotten spreadsheet. ADP Workforce Now security roles should include machine identities whenever an integration can read or write workforce data. A broad machine account can expose more records than a single practitioner, so it belongs in every serious access review.
How to audit ADP Workforce Now security roles
A security review works best when it starts from people and duties, then checks the system against that approved model. Auditing ADP Workforce Now security roles against expected access makes copied profiles and old exceptions easier to identify. Don’t begin by asking whether current access “looks normal.” Current access may already contain years of copied profiles, temporary exceptions, transfers, and old integrations. Build the expected access first, then compare it with reality.
Use this review sequence:
1. List every user and integration with Workforce Now access. Include employees, managers, practitioners, privileged administrators, outside service users, and connected applications.
2. Confirm the user’s current job and owner. For integrations, identify the business and technical owner.
3. Write the required functions. Note the menus, reports, approvals, or transactions needed for assigned work.
4. Define the worker population. Record whether access should cover the user’s own record, direct reports, a business unit, a company code, a pay group, or the full workforce.
5. Separate view from edit. Don’t grant change rights where reading a report is enough.
6. Review ADP Workforce Now People Access. Confirm that the user can’t reach workers outside the approved population without a documented reason.
7. Review ADP Payroll Processing Access. Confirm company and payroll scope separately from general employee visibility.
8. Check sensitive fields. Review tax IDs, bank data, birth dates, compensation, benefits, and other restricted information.
9. Review security administration. Identify who can grant access and whether those rights are still required.
10. Test the role. Use an approved test process to confirm the user can complete required work and can’t reach restricted data.
11. Record exceptions. Document the owner, reason, approval, and expected end date for unusual access.
12. Remove what isn’t justified. A permission without a current business reason shouldn’t survive the review.
The final audit record should be understandable to someone who didn’t configure the system. That means naming the role, its purpose, the allowed population, sensitive-data decisions, and any exceptions. A short explanation is more useful than a screenshot with dozens of selected boxes and no context.
When to review and remove access
Access reviews shouldn’t wait for an annual calendar event. NIST guidance says privileges should be reviewed at an organization-defined frequency and reassigned or removed when necessary. Your formal schedule can follow company policy, but event-driven reviews should happen whenever a person’s job or the system changes in a way that can alter access needs.
Review ADP Workforce Now security roles when someone joins HR or payroll, changes departments, becomes a manager, moves between business units, covers another payroll, or leaves the company. ADP Payroll Processing Access should be part of the same event-driven check whenever payroll responsibility changes. Review them when a new module goes live, a company code is added, an acquisition changes reporting relationships, or an integration is installed or retired. Temporary project access should have a planned end date rather than depending on someone remembering it later.
Pay special attention to transfers. A transferred employee can accumulate new access without losing the old population or old function. Managers can keep former teams if ADP Workforce Now People Access isn’t updated with the reporting change. HR practitioners can keep previous regions. Payroll processors can keep company codes they no longer own. These access leftovers are easy to miss because every individual permission may have been legitimate at the time it was granted.
A repeatable ADP security role checklist gives each review the same standard. Confirm current duties, current population, edit rights, sensitive data, and privileged access. Remove anything that no longer supports the person’s work.
Keep access tied to current work
The best ADP Workforce Now security roles are easy to explain. An employee sees personal self-service information. A manager sees the team information required for supervision. HR, payroll, benefits, finance, compensation, and recruiting users receive the populations and fields needed for their assigned work. Security administrators control access without collecting unrelated operational rights, and integration accounts receive only the data their connection requires.
That model depends on more than role names. ADP Workforce Now permissions should be reviewed across function access, ADP Workforce Now People Access, ADP Payroll Processing Access, view versus edit rights, and sensitive-field visibility. When those decisions are documented separately, broad access is easier to spot and temporary exceptions are easier to remove.
Use the ADP security role checklist as a living control. Every material job change, payroll-scope change, module change, or integration change can alter what a user should see. Access that matched a person’s job last year may be excessive today. Keeping access tied to current work is the simplest standard for deciding who should see what.
FAQs
What are ADP Workforce Now security roles?
ADP Workforce Now security roles are the access arrangements that determine what users can reach and do in the system. In practice, the decision should include functions, employee populations, view or edit rights, payroll scope, and sensitive-data visibility rather than relying on a job title alone.
Who should have full access to ADP Workforce Now?
Full access should be rare. Most users can complete their work with a defined set of functions and employee populations. Privileged security access should be limited to people who actually administer access, and broad operational access should require a documented business reason.
What is ADP Workforce Now People Access?
ADP Workforce Now People Access controls which workers a practitioner can reach. It should match the population the person supports, such as a business unit, region, manager hierarchy, or another approved group. It should be rechecked after transfers and organizational changes.
What is ADP Payroll Processing Access?
ADP Payroll Processing Access controls the payroll population a practitioner can process or work with based on the permissions available in the organization’s configuration. It should be reviewed separately from general employee visibility because seeing a worker record doesn’t automatically justify payroll-processing rights.
Should managers see employee salaries in ADP Workforce Now?
Only when salary information is required for their assigned work. Managers involved in compensation planning may need selected pay information for their teams. Managers who don’t make pay decisions may need less. Salary visibility should be an explicit policy and permission decision.
Should HR have access to payroll in ADP Workforce Now?
HR should have payroll access only when HR duties require it. Many HR tasks need employee records and compensation context without requiring payroll processing. Review payroll menus and Payroll Processing Access separately rather than granting them because the user works in HR.
Should payroll users see bank account information?
Only users whose payroll duties require bank information should have the necessary visibility. Other payroll reviewers may be able to complete their work with masked values or reports. Bank access should be treated as a sensitive-field decision rather than a default payroll permission.
Should finance have edit access to employee records?
Finance often needs payroll totals, general ledger outputs, and labor-cost detail without needing to edit employee records. If finance needs employee-level detail for reconciliation, view-only reporting may be enough. Persistent edit rights should have a specific business reason.
What should a benefits administrator see?
A benefits administrator may need eligibility, elections, dependents, beneficiaries, plan information, and related reports. That role doesn’t automatically require payroll-processing access, bank details, or unrelated compensation functions. Access should follow the benefits work assigned to the user.
How should recruiter access be limited?
Recruiters generally need candidate, requisition, offer, and hiring information. Access to payroll, tax setup, direct deposit, and unrelated employee compensation should usually remain outside the recruiting role unless a documented onboarding responsibility requires a specific field.
Who should manage ADP Workforce Now permissions?
Access administration should be limited to a small set of authorized users with a defined security responsibility. Where practical, security administration should be separated from routine payroll and HR transactions. Every person with privileged access should have a current reason for keeping it.
How often should ADP security roles be reviewed?
Use a formal review frequency set by company policy and add event-driven reviews. Role changes, manager changes, transfers, payroll coverage changes, new modules, new integrations, and terminations should trigger a check because each can change what access is still justified.
What sensitive fields should be reviewed in ADP Workforce Now?
Review tax identifiers, birth dates, bank information, routing numbers, compensation, tax withholding, deductions, garnishments, dependent information, and personal contact data. The exact list should reflect your modules, policies, and legal requirements.
Do ADP integrations need their own security review?
Yes. An integration can read or write large volumes of employee data without an interactive user. Review its owner, worker population, fields, write permissions, credentials, and sensitive-data access. Remove connections that no longer serve an active business purpose.
What is the best way to use an ADP security role checklist?
Use it to compare approved access with actual access. Document the person’s current duties, required functions, allowed worker population, payroll scope, edit rights, sensitive fields, and exceptions. Then test the role and remove permissions that no longer support the user’s work.
