July 30, 2026
AP Transactions: Updated AP Transactions page and new Memorized Transactions tab
The AP Transactions page has been updated! In addition to its new look, the AP transactions page now has a Memorized AP Transactions tab. This page brings AP invoices, credit memos, and payments together in one searchable, filterable list, replacing the separate legacy views. The Memorized AP Transactions tab replaces the standalone Memorized AP Transactions page, adding schedule status and template management directly in the grid.
This update includes the following:
A new AP Transactions grid
A bulk action toolbar for Approve, Unapprove, Print Checks, Delete, and Send to R365 Payments, with additional actions for payment holds, check stubs, transaction summary, and 1099 updates
A Memorized AP Transactions tab on the AP Transactions page, replacing the standalone page
Status badge, next run date, and repeat count visible for each memorized template directly in the grid
Pause and resume for memorized templates, individually or in bulk across multiple selected rows
Quick filters on the memorized tab: Active, Completed, Paused, Due this week, and Expiring soon
July 27, 2026
Ends With function added to Bank Activity Rule Builder
The rule condition editor in the Rule Vault now includes an Ends With function, joining Equal To, Contains, and Starts With in the Function dropdown. This function lets banking rule builders match values that end in a known pattern, such as a vendor code or account suffix, without over-matching the way Contains might.
Ends With is available in the following contexts:
For Bank Activity sources, on the Name and Comment fields.
For R365 transaction sources, on the Location, Comment, Check Memo, and Vendor fields.
Across all rule types that support string conditions: Matching, Payment Group Matching, Create Transaction, and Custom Matching.
Learn more about creating matching rules and transactions rules in the Rule Vault.
July 16, 2026
New Daily Sales Summary Permission: Edit Guest Count
A new Edit Guest Count permission is now available. This permission enables users to edit the Guest Count field on the Daily Sales Summary (DSS). When the permission is disabled for a role or user, the Guest Count field on Daily Sales Summary records is read-only. The permission applies to both New DSS and Classic DSS.
POS integration writes to Guest Count are not blocked by this permission and proceed regardless of how it is configured.
At release, the permission defaults to off for all roles except Full Access and Admin,
New Users & Security Permission: Edit Users in Bulk
A new Edit Users in Bulk permission is now available. This permission controls access to two bulk-editing entry points: the Mass Role Update page and the bulk-edit checkboxes on the Users table.
The two permissions are linked. Edit Users in Bulk requires Edit Users to be active; enabling Edit Users in Bulk automatically enables Edit Users, and disabling Edit Users automatically disables Edit Users in Bulk.
Upon first enablement of this feature, the system automatically grants Edit Users in Bulk to any role or user that already has Edit Users, so existing access is preserved without manual reconfiguration.
Roles without Edit Users in Bulk cannot access the Mass Role Update page, including via direct URL navigation, and the bulk-edit checkboxes on the Users table do not appear.
New Integrations Permissions: Control by Integration Type
Posted to COE-250. Once you have the article URL, just share it and I'll update the comment with a "Learn more" line.
Here's the release note:
Users & Security: new Edit Users in Bulk permission
A new Edit Users in Bulk permission is now available under Users & Security > Users. It sits alongside Edit Users and independently controls access to two bulk-editing entry points: the Mass Role Update page and the bulk-edit checkboxes on the Users table.
The two permissions are linked. Edit Users in Bulk requires Edit Users to be active; enabling Edit Users in Bulk automatically enables Edit Users, and disabling Edit Users automatically disables Edit Users in Bulk. On first enablement of this feature, the system automatically grants Edit Users in Bulk to any role or user that already has Edit Users, so existing access is preserved without manual reconfiguration.
Roles without Edit Users in Bulk cannot access the Mass Role Update page, including via direct URL navigation, and the bulk-edit checkboxes on the Users table do not appear.
Daily Sales Summary: new Edit Guest Count permission
A new Edit Guest Count permission is now available under the Daily Sales permission tree. When the permission is off for a role or user, the Guest Count field on Daily Sales Summary records is read-only. When on, the field behaves as it does today. The permission applies to both New DSS and Classic DSS.
POS integration writes to Guest Count are not blocked by this permission and proceed regardless of how it is configured.
At release, the permission defaults to off for all roles except Full Access and Admin, which default to on. The permission can be configured in two places:
Admin > Users & Security > Security & Permissions > User Roles > [Role] > Permissions > Daily Sales > Edit Guest Count
Admin > Users & Security > Users > [User record] > Permissions > Daily Sales > Edit Guest Count
Things to consider
No documentation link is included. Add a "Learn more" line once the article is confirmed live.
The note calls out Full Access and Admin as the default-on exceptions — confirm these are the only two, or flag if there are others.
Do you have a Jira task key to post this to, and is documentation confirmed ready?
Integrations: new permission controls by integration type
Integration type visibility in Admin > Integrations is now controlled by permission. HR, Payroll, Invoices, and POS integration cards are hidden for users without a view, sync, or admin permission for that integration type. Security roles can now be scoped at the integration type level, supporting least-privilege access to sensitive integration configuration.
When a user has no integration type permissions and no Mapping Tool access, the Integrations menu item in the left navigation is hidden entirely.
Each integration type supports three permission tiers, configured under Admin > Users & Security > Security & Permissions:
View Only: read-only access to integration cards and connection status
Sync or Polling: ability to trigger sync and polling operations
Admin: full control, including connect, disconnect, and settings management
This feature is enabled per client; contact your account team to request activation.
Posted to COE-250. Once you have the article URL, just share it and I'll update the comment with a "Learn more" line.
Here's the release note:
Users & Security: new Edit Users in Bulk permission
A new Edit Users in Bulk permission is now available under Users & Security > Users. It sits alongside Edit Users and independently controls access to two bulk-editing entry points: the Mass Role Update page and the bulk-edit checkboxes on the Users table.
The two permissions are linked. Edit Users in Bulk requires Edit Users to be active; enabling Edit Users in Bulk automatically enables Edit Users, and disabling Edit Users automatically disables Edit Users in Bulk. On first enablement of this feature, the system automatically grants Edit Users in Bulk to any role or user that already has Edit Users, so existing access is preserved without manual reconfiguration.
Roles without Edit Users in Bulk cannot access the Mass Role Update page, including via direct URL navigation, and the bulk-edit checkboxes on the Users table do not appear.
Daily Sales Summary: new Edit Guest Count permission
A new Edit Guest Count permission is now available under the Daily Sales permission tree. When the permission is off for a role or user, the Guest Count field on Daily Sales Summary records is read-only. When on, the field behaves as it does today. The permission applies to both New DSS and Classic DSS.
POS integration writes to Guest Count are not blocked by this permission and proceed regardless of how it is configured.
At release, the permission defaults to off for all roles except Full Access and Admin, which default to on. The permission can be configured in two places:
Admin > Users & Security > Security & Permissions > User Roles > [Role] > Permissions > Daily Sales > Edit Guest Count
Admin > Users & Security > Users > [User record] > Permissions > Daily Sales > Edit Guest Count
Things to consider
No documentation link is included. Add a "Learn more" line once the article is confirmed live.
The note calls out Full Access and Admin as the default-on exceptions — confirm these are the only two, or flag if there are others.
Do you have a Jira task key to post this to, and is documentation confirmed ready?
Integrations: new permission controls by integration type
Integration type visibility in Admin > Integrations is now controlled by permission. HR, Payroll, Invoices, and POS integration cards are hidden for users without a view, sync, or admin permission for that integration type. Security roles can now be scoped at the integration type level, supporting least-privilege access to sensitive integration configuration.
When a user has no integration type permissions and no Mapping Tool access, the Integrations menu item in the left navigation is hidden entirely.
Each integration type supports three permission tiers, configured under Admin > Users & Security > Security & Permissions:
View Only: read-only access to integration cards and connection status
Sync or Polling: ability to trigger sync and polling operations
Admin: full control, including connect, disconnect, and settings management
This feature is enabled per client; contact your account team to request activation.
Posted to COE-250. Once you have the article URL, just share it and I'll update the comment with a "Learn more" line.
Here's the release note:
Users & Security: new Edit Users in Bulk permission
A new Edit Users in Bulk permission is now available under Users & Security > Users. It sits alongside Edit Users and independently controls access to two bulk-editing entry points: the Mass Role Update page and the bulk-edit checkboxes on the Users table.
The two permissions are linked. Edit Users in Bulk requires Edit Users to be active; enabling Edit Users in Bulk automatically enables Edit Users, and disabling Edit Users automatically disables Edit Users in Bulk. On first enablement of this feature, the system automatically grants Edit Users in Bulk to any role or user that already has Edit Users, so existing access is preserved without manual reconfiguration.
Roles without Edit Users in Bulk cannot access the Mass Role Update page, including via direct URL navigation, and the bulk-edit checkboxes on the Users table do not appear.
Daily Sales Summary: new Edit Guest Count permission
A new Edit Guest Count permission is now available under the Daily Sales permission tree. When the permission is off for a role or user, the Guest Count field on Daily Sales Summary records is read-only. When on, the field behaves as it does today. The permission applies to both New DSS and Classic DSS.
POS integration writes to Guest Count are not blocked by this permission and proceed regardless of how it is configured.
At release, the permission defaults to off for all roles except Full Access and Admin, which default to on. The permission can be configured in two places:
Admin > Users & Security > Security & Permissions > User Roles > [Role] > Permissions > Daily Sales > Edit Guest Count
Admin > Users & Security > Users > [User record] > Permissions > Daily Sales > Edit Guest Count
Things to consider
No documentation link is included. Add a "Learn more" line once the article is confirmed live.
The note calls out Full Access and Admin as the default-on exceptions — confirm these are the only two, or flag if there are others.
Do you have a Jira task key to post this to, and is documentation confirmed ready?
Integrations: new permission controls by integration type
Integration type visibility in Admin > Integrations is now controlled by permission. HR, Payroll, Invoices, and POS integration cards are hidden for users without a view, sync, or admin permission for that integration type. Security roles can now be scoped at the integration type level, supporting least-privilege access to sensitive integration configuration.
When a user has no integration type permissions and no Mapping Tool access, the Integrations menu item in the left navigation is hidden entirely.
Each integration type supports three permission tiers, configured under Admin > Users & Security > Security & Permissions:
View Only: read-only access to integration cards and connection status
Sync or Polling: ability to trigger sync and polling operations
Admin: full control, including connect, disconnect, and settings management
This feature is enabled per client; contact your account team to request activation.
Integration type visibility in Admin → Integrations is now controlled by permission. HR, Payroll, Invoices, and POS integration cards are hidden for users without a view, sync, or admin permission for that integration type. Security roles can now be scoped at the integration type level, supporting least-privilege access to sensitive integration configuration.
When a user has no integration type permissions and no Mapping Tool access, the Integrations menu item in the left navigation is hidden entirely.
Each integration type supports three permission tiers:
View Only: read-only access to integration cards and connection status
Sync or Polling: ability to trigger sync and polling operations
Admin: full control, including connect, disconnect, and settings management
July 6, 2026
Match and merge duplicate employee records
The Employees area in Workforce includes a new Match + Merge experience that identifies duplicate employee records and combines them into a single primary record. When an employee record has a likely duplicate, a Suspected duplicate records banner appears on the record. Selecting Review + Merge opens a wizard that recommends a primary record, either the most complete record or the record that has received an R365 Payroll payment, and steps through which duplicate records to merge. The previous View Proposed Merges button is removed.
A Merge History tab on the primary record lists the records merged into it and provides a Restore action to separate a record that was merged in error. This gives Workforce and Payroll admins one accurate record per employee across locations, with a clear audit trail and a reliable way to recover from a mistaken merge. The experience is available to users with the Merge Employees permission.
A few behaviors to note:
The record that has received an R365 Payroll payment is always the primary record and cannot be changed.
Selecting Ignore Merge Recommendation dismisses a suspected match and removes the banner from the record.
Personally identifiable information on a merged record is removed during the merge, so it must be re-entered if the record is later unmerged.
Merges completed through the manual or bulk merge tools use the previous wizard and do not appear in the Merge History tab, so they cannot be unmerged.
July 1, 2026
R365 Developer Hub: full Public API documentation and standardized endpoints now available!
The R365 Public API is now fully documented in the R365 Developer Hub, covering 68 endpoints across eight areas of the platform: Accounting, Inventory, Brand Management, Core, User Management, Sales, Labor, and POS. Each endpoint follows a consistent URL convention with complete request and response references, parameter details, and error documentation.
The Public API supports both reading and writing data and covers significantly more of the platform than OData, including new endpoints in this release for Daily Sales, Labor Punches, Labor Jobs, Labor Employees, Journal Entry creation, and Legal Entity. Existing integrations continue to work during the transition, and both the new and current ("Connector") endpoints are documented under the same hub. For new integrations or updates to existing ones, the Public API is the recommended path forward. To request credentials and access scopes, contact your CSM.
Learn more about R365 Public API documentation.
Not sure which to use?
If you need to… | Use |
|---|---|
Build a new REST integration | R365 Public API |
Migrate an existing integration to the modern API surface | R365 Public API |
Maintain an existing integration not yet migrated | R365 API Connector (legacy) |
Query R365 data directly from Snowflake | Secure Data Share |
Updated POS Mapping Tool
The POS Accounts tab in the Mapping Tool has a new look! The updated layout includes a Views bar, Search, and grid options for filtering and managing columns.
A Classic view toggle is available in the upper-right corner of the tab for users who prefer the previous layout. Toggling it on switches back to the classic list view.
Learn more about the Mapping Tool Page.
