Paylocity User Management Guide

• Model type: hybrid
• Description: Paylocity uses a combination of predefined system roles and custom Security Groups. Admins assign users to Security Groups that control module-level access (view/edit/approve) and can further restrict access by employee population (e.g., by department, location, or company). Role inheritance follows the org chart for manager-level access.
• Custom roles: Yes
• Custom roles plan: Included in standard subscription; no separate upgrade documented
• Granularity: Module-level with action-level controls (view, edit, approve) and employee-population scoping by department, location, or company code

1. Log in to Paylocity at access.paylocity.com with an administrator account.
2. Navigate to HR & Payroll > Employee > Add Employee (for new employee records) or HR & Payroll > User Access for standalone user/admin accounts.
3. Enter required employee or user information including name, email address, and employee ID.
4. Assign the user to the appropriate Security Group(s) to define their access level.
5. Set the user's start date and employment status.
6. Save the record. Paylocity will send a welcome/activation email to the user's email address on the configured start date or immediately if the date is today or past.
7. For admin or non-employee users, use HR & Payroll > User Access > Add User and assign Security Group without creating a full employee record (if supported by your configuration).

Required fields: First name, Last name, Email address, Employee ID (auto-generated or manual), Start date, Security Group assignment

Watch out for:

• User accounts in Paylocity are tied to employee records; there is no fully separate 'admin-only' user type that is completely decoupled from an employee record in most configurations.
• Welcome/activation emails are triggered automatically; ensure the email address is correct before saving to avoid sending credentials to the wrong address.
• Security Group must be assigned at creation or the user will have no meaningful access beyond basic self-service.
• SSO must be configured separately; creating a user does not automatically enroll them in SSO.

• Can delete users: No
• Delete/deactivate behavior: Paylocity does not allow permanent deletion of employee or user records due to payroll tax compliance and audit trail requirements. Users are terminated/deactivated, which revokes system access while preserving all historical records. This is standard for payroll systems subject to IRS and state record-retention regulations.

1. Navigate to HR & Payroll > Employee and locate the employee record.
2. Open the employee's profile and go to the Employment tab.
3. Enter the termination date and select the termination reason from the dropdown.
4. Save the termination record. System access is revoked as of the termination date (or immediately if the date is today or past).
5. If the user has a separate admin/user access account, navigate to HR & Payroll > User Access, locate the user, and deactivate or remove their Security Group assignments.
6. If SSO/SCIM is in use, deprovisioning via the IdP will also revoke Paylocity access automatically.

Watch out for:

• Termination date determines when access is revoked; setting a future termination date means the user retains access until that date.
• Rehired employees require reactivation of the existing record rather than creation of a new one to preserve historical data and avoid duplicate records.
• If the terminated employee was the only administrator, another admin must be designated before completing termination to avoid being locked out of the system.
• COBRA and benefits continuation workflows may be triggered automatically upon termination; review configuration to avoid unintended notifications.

• Where to check usage: HR & Payroll > Reports > Employee Reports (run active employee count report); specific license usage dashboard not publicly documented
• How to identify unused seats: Run an Active Employee report filtered by last login date or access date. Paylocity does not prominently surface a 'last login' field in standard reports; this may require a custom report or contacting Paylocity support for access log data.
• Billing notes: Paylocity pricing is per-employee per-month and is typically negotiated annually. Implementation fees of 10–20% of annual software fees apply. Billing is based on employees processed in each pay period, so headcount fluctuations affect monthly costs. Exact pricing requires a quote; published rates are estimates only.

Active employees are billed per-employee per-month; terminated records are retained for compliance but are not counted toward active headcount after the termination date. Paylocity does not surface a native last-login report in standard views, so identifying unused or stale accounts requires building a custom report or engaging Paylocity support for access log data.

Because billing tracks employees processed each pay period, undetected ghost accounts or delayed terminations directly inflate monthly costs.

Administrators consistently flag Security Group configuration as complex and non-intuitive, requiring significant trial and error to scope permissions correctly.

Manager access is driven entirely by the org chart - an incorrect reporting hierarchy causes access gaps or unintended data exposure across every app that inherits those relationships.

Offboarding is a multi-screen manual process (termination record, Security Group removal, SSO deprovisioning) unless SCIM is active, which is gated to the Enterprise tier.

G2 and Reddit reviewers also note slow support response times for access and permission issues, particularly for accounts without a dedicated account manager.

Common complaints:

• Administrators report that Paylocity's Security Group configuration is complex and non-intuitive, requiring significant trial and error to achieve the correct permission scope.
• Users note that the org chart must be meticulously maintained because manager access is entirely driven by reporting relationships; incorrect hierarchy causes access gaps or over-exposure.
• HR teams report difficulty identifying inactive or unused user accounts because Paylocity does not provide a built-in 'last login' report in standard reporting views.
• Offboarding workflows require manual steps across multiple screens (termination record, Security Group removal, SSO deprovisioning) unless SCIM is configured, which requires the enterprise tier.
• Some administrators report that welcome/activation emails are sent immediately upon record creation regardless of future start dates, causing confusion for pre-boarded employees.
• Reviewers on G2 and Reddit note that Paylocity's customer support response times for access and permission issues can be slow, particularly for mid-market customers without a dedicated account manager.

Use manual administration if your headcount is stable, your org chart is meticulously maintained, and you have an administrator with capacity to manage terminations across multiple screens. Prioritize SCIM provisioning if offboarding speed and consistency matter - delayed terminations leave access open until the termination date is explicitly set.

Custom Security Roles are available in the standard subscription and should be configured before onboarding begins; a missing Security Group assignment at creation leaves users with only basic self-service access.

Bottom line

Paylocity's manual access model is functional but operationally demanding. Security Groups require careful upfront design, the org chart must stay accurate to prevent manager-level over-exposure, and offboarding requires deliberate action across multiple screens.

Every app downstream that consumes Paylocity employee data inherits any gaps left by incomplete or delayed access changes.

Teams managing more than a few dozen employees, or with frequent turnover, will find the manual process error-prone without a documented runbook and a clear owner for each step.