The items below are the known limitations of the iPaaS.com Revel integration. They are inherent to the current design of the integration and to the capabilities of the Revel API at the time this documentation was written, and they apply to all subscribers. This initial release supports employee and timesheet synchronization.

This integration was built for Revel Systems, the point-of-sale platform, and its REST API.

The integration does not perform a bulk import of existing employees or timesheets when it is first connected. Synchronization begins from the point the integration starts running.

What this means for you: Your existing Revel employee roster and past timesheets are not pulled in automatically on day one. To seed historical records, subscribers or their MiSP can use bulk sync using Postman. Ongoing changes flow normally once the integration is running.

Revel does not notify iPaaS.com when a record changes, so the integration checks Revel for changes on a schedule that subscribers or their MiSP set. A change made in Revel appears in iPaaS.com on the next scheduled check rather than instantly.

What this means for you: There is a short delay between a change in Revel and its appearance in iPaaS.com, determined by how often the integration is scheduled to poll. You can set the cadence, and run an on-demand check at any time, from Dashboard / Integration Monitoring / Events.

The employee and timesheet collections add new records and update existing ones. They do not delete records.

What this means for you: Removing an employee or a timesheet entry in one system does not remove the matching record in the other. If you need records removed on both sides, remove them in each system directly.

When the integration updates a record in Revel, it writes only the fields that are mapped. Any other value already on the Revel record is left as it is.

What this means for you: For the fields it manages, the source system is the source of truth — those values are refreshed on every transfer. Values you maintain only in Revel, on fields the integration does not map, are not overwritten. If both directions of a collection are enabled at once, review the mapping filters so a change written by one direction does not immediately flow back through the other.

A timesheet is attached to an employee, so the employee must already be present and linked in the destination system before a timesheet for that employee can transfer. When synchronizing timesheets into iPaaS.com, a timesheet whose employee is not yet linked is skipped quietly and transfers on a later run once the employee is present. When writing timesheets into Revel, the transfer fails if the employee does not yet exist in Revel.

What this means for you: Synchronize employees before timesheets. If a timesheet is missing, the most common reason is that its employee has not been synchronized yet. Because inbound timesheets for an unlinked employee are skipped rather than reported as errors, confirm the employee is present before investigating a missing shift.

A shift that is still in progress has no clock-out time. It transfers with the start time populated and the end time and total hours empty, and is completed on a later transfer once the shift is closed.

What this means for you: An in-progress shift appears with no end time until it is closed in Revel and transferred again. This is expected; the record fills in once the shift ends and the collection runs again.

Revel records how long a break lasted but not when it started. The integration places the break at the start of the shift and calculates its end from the recorded length.

What this means for you: Break duration is accurate, but the time of day a break is shown at is not the moment it was actually taken. For totalling paid versus break time this is exact; if your reporting depends on when in the shift a break occurred, that detail is not available from Revel.

The integration does not read from or write to custom fields defined in Revel.

What this means for you: Only the standard employee and timesheet fields the integration maps are synchronized. Data held in Revel custom fields is not transferred. (This is separate from the iPaaS.com-side custom fields the integration uses to hold an employee's PIN and start date, which are supported and described in the mapping documentation.)

Revel can hold an employee's establishment, role, and hourly wage on a separate assignment record. The integration is able to write that assignment, but the mappings for it are not configured by default.

What this means for you: By default, synchronizing an employee to Revel does not set their establishment, role, or wage assignment. If you need those written, subscribers or their MiSP can add the corresponding mappings. If your workflow needs this configured as standard, submit a feature request through your iPaaS.com partner channel describing the requirement.

When synchronizing timesheets into iPaaS.com, the integration carries the core shift — employee, start and end times, remarks, and calculated hours. The role worked, the hourly wage applied, the department, and Revel's approval or processing stage are not carried across.

What this means for you: iPaaS.com timesheets reflect who worked and for how long, not the pay rate or approval state recorded against the shift in Revel. If you need that detail downstream, note that it stays in Revel for this release.

Revel documents its date and time values as ISO 8601 but does not publish a literal format or state whether values are interpreted in UTC or in the establishment's local time zone.

What this means for you: For most single-location accounts this is not noticeable. Where establishments span more than one time zone, or where shifts run across midnight, confirm that times land on the expected day and hour in a staging environment before relying on the integration for payroll.

Revel enforces a daily allowance on the number of API calls an account may make, but does not publish the specific figure. When the allowance is exhausted, Revel rejects further requests until it resets, and the rejection appears in Dashboard / Integration Monitoring / Error Logs.

What this means for you: Under normal operation you are unlikely to reach the allowance. When running large transfers, stagger them rather than running several intensive jobs at once. If you reach the limit regularly, contact iPaaS.com Support at support@ipaas.com.

The integration ships with a small number of example values that must be reviewed and replaced with values that are valid for your own Revel account before the affected collections are enabled. Leaving them in place produces records that look valid but carry the wrong data.

This article covers 12 known limitations and 3 placeholder values to review before go-live. For detailed technical documentation of each employee and timesheet collection, see the mapping collection descriptions in the iPaaS.com subscription mapping page and the related mapping documentation articles.