Getting Ready for NICE CXone 26.4: Audit Your Scripts, Lists and Staffing Plans Before It Reaches Your Tenant

The 26.4 cycle began on October 26, 2026 and runs until the next release, currently targeted for February 4, 2027 — but that start date is not the day anything switches on in your tenant. CXone releases roll out tenant by tenant, so 26.4 is best treated as a window, not a deadline. The good news is that the most useful work in this cycle is not waiting for enablement at all. It is housekeeping you can start today: a Studio pattern that will quietly block urgent saves, outbound calling lists whose names no longer meet the rules, and a staffing model that will not move until your WFM team tells it to. Administrators, Studio developers and planners who audit those three areas now will meet 26.4 with a checklist already ticked off instead of a surprise.

What changed

Three items matter most. First, a Studio validation change marked Action Required: Web Studio will refuse to save a script whose ONRELEASE branch contains an END action, and Personal Connection calling list names are now restricted to letters, numbers, hyphens and underscores (details). Second, an enhancement to WFM staffing: for real-time skills in True to Interval forecasts, staffing is now recalculated against Service Level and ASA targets rather than being driven by occupancy alone (details). Third, a set of access-control fixes published on October 27 in Fixed and Known Issues, covering report restrictions, dashboard scope, API permissions, mobile schedule visibility and a failover gap (details).

Before it lands: a pre-upgrade audit checklist

Work through these while the rollout is still travelling toward you:

• Find every ONRELEASE branch with an END in it. END itself triggers ONRELEASE, which is why an END inside that branch causes problems. Running scripts do not break — but the next time you open one to make an urgent fix, the save will be refused until the END is removed. No replacement action is needed; the branch ends on its own.
• Inventory your Personal Connection calling lists. Flag any name containing spaces or characters such as : / ? # @ & %. Names like that can make operations fail to locate the list. Existing lists are not renamed automatically, so rename on your schedule — and list every integration, scheduled job and report that references the old name before you do.
• Re-verify access boundaries. The October 27 fixes — RPT-56861, CXDV-81756, AAD-49636, CXWFM-91704 and ORC-53647 — touched Contact History report restrictions, dashboard data scope, view-only Admin API roles changing skill states, unpublished schedules appearing in the mobile app, and global script variables not replicating to standby servers, after which calls were refused following a failover. Fixes deploy on their own timing per tenant, so check your service notification, then spot-check each boundary in your own configuration rather than assuming.
• Note which forecasts are real-time and True to Interval. Those are the ones the new staffing calculation applies to. Deferrable workloads and imported data are unchanged, so leave them out of the 26.4 review pack.

A pattern for governing Studio scripts and outbound lists

Treat the ONRELEASE rule as a coding standard, not a one-off cleanup. For example, a simple pattern that works in most shops: add "no END in ONRELEASE" to your Studio peer-review checklist, keep a shared register of scripts that were remediated, and store the emergency version of that checklist somewhere an on-call developer can reach at 2 a.m. — because the failure mode here is not a broken script, it is a blocked save during an incident.

Apply the same discipline to list names, because lists are where outside systems touch CXone. Picture a typical CRM-fed flow as an example: a nightly segment export from a CRM such as Salesforce or Microsoft Dynamics 365 lands in a staging folder, a small validation step checks the file and its target list name against the allowed characters, and only then is the list loaded for Personal Connection dialling. The naming rule gives that validation step something concrete to enforce. Build the sanitised name — letters, numbers, hyphens, underscores — at the point where the list is created in the CRM or the integration layer, not by hand in CXone afterwards. When you do rename an existing list, rename it in the source system and every downstream reference in the same change window, then run one low-volume test campaign to prove the renamed list is found.

Re-planning staffing under the SLA-driven model

The WFM change rewards planners who prepare a comparison instead of flipping a switch. In Staffing Parameters, a Service Level target, an ASA target, or both are now required; Maximum Occupancy becomes an optional cap and can no longer be the only parameter. Under the new calculation, headcount stops growing once the targets are met, and workload is distributed across intervals using received volume and AHT, including carry-over contacts.

Nothing changes under you automatically: existing forecast jobs keep the old calculation until someone selects a target and regenerates staffing. Use that as an opportunity. As an example workflow, copy a current forecast for a busy real-time skill, set the Service Level and ASA targets your operation actually commits to, keep Maximum Occupancy as a sanity cap, regenerate, and compare the two plans interval by interval — where does headcount fall because targets are already met, where does carry-over push requirement into the next interval, and what does the difference do to occupancy and cost? Agree the target pair per skill with operations before you regenerate the live forecast, and document why those targets were chosen. That way the first SLA-driven plan is a decision people can defend, not a number nobody remembers setting.

Keep reading

The full record for this platform is on the NICE CXone release intelligence page, including the three 26.4 updates this article draws on: Studio validation and calling list names, WFM SLA-driven staffing and the access-control fixes. For the source material itself, work from NICE's official release notes (opens in a new tab) and your own tenant's service notification — and remember that in a rolling release, the most valuable upgrade work is the audit you finish before the upgrade arrives.