Capabilities
What changes in day-to-day work
Data originates where the process is happening anyway (in the preboarding form, in a request, at a salary change) and reaches the HR and payroll system without retyping.
Hiring without an intermediate spreadsheet
Leave and remote work requests
Payslips and PIT-11 forms in the employee's folder
Offboarding run from one place
How it works
What syncs, and in which direction
The exchange is two-way, but each object has one side that is its source of truth. The sync is launched from the list of PeopleForce employees visible in enova365, filtered by the date of the last change.
| What moves | Direction | When | Data scope |
|---|---|---|---|
Employee record Basic, address, insurance and tax details | PeopleForce enova365 | on sync scope of the first import agreed during implementation | PESEL, ID document, addresses, NFZ and ZUS branch, municipality GUS code, NIP, tax office |
Contracts Employment contracts (permanent, fixed-term, probationary), mandate contracts (umowa zlecenie), specific-task contracts (umowa o dzieło), B2B | PeopleForce enova365 | on sync requires contract type mapping | contract type, period, salary, working time (FTE), position, department, occupation code |
Pay supplements Bonuses, commissions, other components | PeopleForce enova365 | on sync requires component name mapping | component name, amount, validity period |
Leave requests Approved only | PeopleForce enova365 | on sync approved only; a withdrawn request is deleted | leave type, date range, employee |
Remote work requests Approved only | PeopleForce enova365 | on sync approved only | date range, employee |
Bank account numbers | PeopleForce enova365 | on sync the source field is specified in the configuration | account number, bank, currency, account holder |
Documents Electronically signed contracts and addenda | PeopleForce enova365 | on sync | document file linked to the employee |
Leave entitlements Balance update | enova365 PeopleForce | on sync | entitlement for the current year, plus carry-over from the previous year |
Pay supplements and deductions Defined in the supplement map | enova365 PeopleForce | on demand for selected employees | currently assigned supplements and deductions |
Contract history Initial load | enova365 PeopleForce | on demand one-off, for selected employees | contract history saved in the “Umowy” (Contracts) table in the employee profile in PeopleForce |
Absences from enova365 Including sick leave | enova365 PeopleForce | on demand for selected absences | date range, number of days used in the employee profile |
Payslips and PIT-11 forms Ready-to-use documents | enova365 PeopleForce | on demand for selected payouts and declarations | PDF file in the employee's folder, optionally password-protected |
Employees in both systems are linked by the PeopleForce identifier, stored in enova365 as an employee attribute (cecha). On the first run, the integrator matches people by PESEL number or employee code and fetches the identifiers automatically; where matching fails, the attribute is filled in by hand. The result shows in the logs under the “PeopleForce” category.
Setup
Two stages to launch
The connection is handled by an enova365 add-on, built by an authorised partner and installed on the enova365 side. A dedicated Customer Success Manager guides you through the whole process, together with the partner responsible for the add-on.
Installing and connecting the systems
Work on the enova365 side is done by the system administrator.
Uploading the add-on licence in the add-on licences section of enova365
Unpacking the add-on libraries and placing them in the database or in the enova365 library directory; files downloaded from the internet have to be unblocked in their properties
Entering the API address and the API key generated in PeopleForce (Settings → Security → API keys, Professional plan)
Mappings and the first sync
The dictionaries of both systems have to be matched before the data exchange starts.
Fetching dictionaries from PeopleForce and matching them with definitions in enova365: supplements, contract types, request types, working-time fractions (FTE)
Items that should stay outside the exchange are marked with a skip parameter
Fetching employee identifiers, matching by PESEL number or employee code, and filling any gaps by hand
The add-on adds its own views in enova365 (lists of changed employees and requests from PeopleForce), and day-to-day work is done from those
You decide how much history to bring over: contracts, tables and insurance data can be transferred from a chosen date, even from several years back
Configuration
What gets agreed during implementation
Every company names its dictionaries its own way, so some matches are set by hand: once at the start, and again whenever a new item appears in PeopleForce.
Item | What needs to be agreed |
|---|---|
API access | The environment address and an API key generated in PeopleForce with the appropriate permission scope |
Pay supplements | Names used internally are matched with supplement definitions in enova365 |
Contract types | Each contract type points to its corresponding object in enova365 and to a default department |
Request types | Leave policies are matched with the definitions of leave requests and remote work requests |
Working-time fractions (FTE) | Full-time is assumed by default; other fractions are set on individual schedules |
Account number field | The PeopleForce field that the account number is taken from |
Document templates | The add-on installs default payslip and PIT-11 templates; you can prepare your own with the Implementation Partner. New declaration templates arrive with later versions of the add-on |
Target folders | Separate folders for payslips and for PIT-11 forms: you specify the folder name in PeopleForce |
Department names | A parameter defines which field the department dictionary is built from on the PeopleForce side; a department without a counterpart goes to the default department |
Conditions for running the integration
Where the add-on runs, what we need from you, and how the launch works.
The add-on runs on the enova365 side
We don't ask for access to your enova365
Start on a test database, then production
Frequently asked questions
What HR teams and accounting firms ask most often before implementation.
Step-by-step guide in the help centerHow is the data exchange started?
The exchange is always initiated by enova365: in the list of PeopleForce employees, you set the date from which you want changes and run the sync. Employee data then goes to enova365, and entitlements come back to PeopleForce. Exporting absences and sending payslips and PIT-11 forms are separate actions on selected records. We agree during implementation who runs them and how often.
Which requests reach enova365?
Only requests with the “Approved” status whose type has been mapped and not marked as skipped. A rejected request is not passed on, and a withdrawn one is deleted on the enova365 side. That way, absences that never actually happened don't show up in the HR system.
How do the systems recognise that it's the same person?
By the PeopleForce employee identifier, stored in enova365 as an attribute. On the first run, the integrator matches people by PESEL number or employee code and fetches the identifiers automatically. If matching fails for someone, the attribute is filled in by hand; the list of such cases is in the logs.
Can an employee request sick leave in PeopleForce?
In this integration, sick leave is not submitted as a request: the information reaches enova365 from eZUS (e-ZLA import), and the integrator passes it on to PeopleForce. The employee profile shows the days used.
What happens when we add a new contract or absence type?
The new item has to be mapped before it starts transferring. You fetch the dictionaries from PeopleForce again and point to the corresponding definition in enova365. It's the same step as at setup, just for one item.
What about a department that doesn't exist in enova365?
Departments are assigned by name. If the integrator finds no counterpart, the contract goes to the default department specified in the mapping configuration, so data isn't left in limbo and the mismatch is visible straight away.
Which side is the source of truth?
The exchange works both ways, but each object has one source of truth: employee data changes are made in PeopleForce, while entitlements, calculated pay (payroll runs) and payroll documents are kept by enova365. If some HR changes in your process originate on the enova365 side, let's discuss before launch how to fit that with this split.
We update enova365 every month. What happens to the add-on?
The add-on is built for a specific version of enova365, so upgrading the system requires a new version of the add-on. Regular plugin updates are part of the integration subscription: the partner responsible for the add-on delivers them, and your account manager at PeopleForce handles the tickets. It's worth reporting planned maintenance windows in advance and not running the sync during an update.
An accounting firm manages our enova365. How does implementation work then?
It's a common setup. Whoever administers enova365 (that is, the accounting firm) installs and maintains the add-on, and your account manager at PeopleForce remains the single point of contact for tickets. It's worth agreeing up front who does the work on the enova365 side and how it is billed, because it usually goes beyond standard HR and payroll services.
What if some data transfers only partially?
Mismatches most often occur with absence entitlements or with data that went through partially. Data stays on the side it came from, so you can work out what failed and transfer the missing part again. Integrator runs are logged on the enova365 side.
How long does implementation take?
For a mid-sized company, usually about a month, from agreeing the scope to working in production. The biggest part is preparing data on the PeopleForce side (fields and leave policies) and mapping dictionaries in enova365. A technical person on the enova365 side is needed for installation and mappings, and later for a new add-on version and mapping new items; day-to-day operation is done in the regular enova365 interface.
How do I start an integration project?
In PeopleForce, go to Settings → Integrations → enova365 and contact the team, or write directly to your account manager. Your account manager launches the integration together with the partner responsible for the add-on; you can't switch it on yourself in settings. The first step is a call where we agree your enova365 package, the person with administrator rights on your side, and the scope of mappings. The ERP Connector is billed separately from the module subscription.
