Sage 300 and Dayforce integration

What moves between them

Employee records and org unit hierarchies flow from Dayforce into Sage 300 on a polling schedule tied to your payroll calendar. Job codes and cost centers configured in Dayforce are mapped to corresponding GL accounts and segments in Sage 300 so that payroll allocations land on valid accounts. The sync is one-way: changes to employee status, job assignment, and organizational affiliation in Dayforce are read by ml-connector and pushed to Sage 300 as updates to employee master data and referenced GL segments.

How ml-connector handles it

ml-connector stores both Sage 300 Basic Auth credentials (uppercase username and password) and Dayforce OAuth credentials encrypted in the database. On every poll cycle, it requests a fresh Dayforce Bearer token from the token server, stores it temporarily, and uses it to fetch changed employee and org unit records using date range filters. It then translates Dayforce organizational units and job codes into Sage 300 GL segments and cost center references, and posts the employee records to Sage 300 using its REST API with Basic Auth. Sage 300's on-premise architecture means the API endpoint is customer-specific, so ml-connector accepts the full instance URL per customer. Because both systems are poll-only, ml-connector runs the sync on your chosen schedule rather than waiting for a push, and it tracks the last successful poll timestamp to avoid redundant fetches. All records carry an audit trail and can be replayed if a downstream write to Sage 300 fails.

A real-world example

A mid-market manufacturing company runs Sage 300 on premise for accounting and operations, and uses Dayforce in the cloud for payroll across three facilities. Before the integration, the finance team exported a monthly employee list from Dayforce and manually posted salary expense totals to Sage 300 by facility, with frequent mismatches between the two systems. When an employee changed departments or was assigned to a project-specific cost center in Dayforce, it took several days for the corresponding Sage 300 GL account assignment to get updated. With Sage 300 and Dayforce connected, ml-connector syncs the employee roster and cost assignments daily, so the GL accounts reflect the live organizational structure, and the finance team no longer re-enters payroll headcount by hand.

What you can do

• •Sync employee records, job codes, and organizational units from Dayforce into Sage 300 on a polling schedule tied to your payroll cycle.
• •Map Dayforce cost centers and organization units to Sage 300 GL segments and accounts so payroll allocations land on valid chart of accounts entries.
• •Handle Dayforce OAuth 2.0 token refresh every hour and Sage 300 HTTP Basic Auth on every request without re-keying credentials.
• •Bridge customer-specific Sage 300 on-premise instance URLs and Dayforce client namespaces so each customer's endpoint configuration is stored once.
• •Poll both systems for changed employee records on your chosen schedule, with a full audit trail and error replay for failed transactions.

Questions

How does ml-connector handle Dayforce OAuth tokens expiring every hour?

ml-connector requests a fresh Dayforce Bearer token at the start of each poll cycle, before fetching employee or org unit records. The token is stored temporarily and used for all calls in that cycle. If a call returns a 401 Unauthorized, the token is refreshed and the request is retried. Token expiry is never allowed to block the sync.

Why must Sage 300 usernames and passwords be uppercase?

Sage 300 HTTP Basic Auth requires uppercase credentials. ml-connector validates and normalizes both the username and password to uppercase before encoding them in the Authorization header. If your Sage 300 account was created with mixed case, ml-connector converts it on every request.

What happens if the Sage 300 on-premise server is unavailable during a sync?

ml-connector logs the failed poll, stores the event in the audit trail, and retries on the next scheduled cycle. The last successful poll timestamp is preserved, so when the server comes back online, the next sync will fetch only the records that changed since the last successful run, avoiding duplicate data entry.