Release 26A: Redwood Absence Management Schema Shifts Explained for HCM Developers

Key Takeaways

What's Actually Changing in Release 26A: Redwood Absence Management Schema Shifts

The Release 26A Redwood Absence Management schema shifts are not just a UI facelift. They change how data is written, read, and surfaced across the ANC namespace in oracle cloud hcm.

The core change: Absence administrative pages now run on Visual Builder Cloud Service (VBCS) instead of the legacy ADF framework. That shift forces REST-based data fetches instead of direct database views, which changes what columns are exposed by default and which join paths your queries need to account for.

Three things matter most for developers and report writers:

• The Expression Builder for accrual and qualification matrices is replaced by the Condition Builder.
• Four new audit columns are now surfaced directly on Absence pages via VBCS.
• Existing plan configurations become read-only until migrated to the new Condition Builder schema structure.

If you query ANC_ tables directly, your SQL still works. But plan criteria stored in the old Expression Builder format will not be editable through the UI. Understand that distinction before you plan any 2026 migration window.

Core Oracle HCM Tables Affected by the 26A Absence Management Schema Shifts

The Release 26A Redwood Absence Management schema shifts touch a specific set of ANC-prefixed tables. Here is the definitive list for developers.

All of these are documented and searchable on hcm-tables.com, where you can pull column-level detail faster than navigating Oracle's official docs.

This infographic highlights the five changes in Release 26A to the Redwood Absence Management Schema, helping teams quickly understand the updates.

The Condition Builder Transition: Impact on Your HCM Data Model

The biggest structural change in the Release 26A Redwood Absence Management schema shifts is the deprecation of the Expression Builder in favor of the Condition Builder for accrual and qualification matrices.

What this means at the data level: plan criteria are now stored in a different serialization format within ANC_ABS_PLANS_F. The hcm data model underneath has not changed its column layout, but the data written into those criteria columns follows new Condition Builder schema rules.

If you have SQL or OTBI reports that parse Expression Builder output columns directly, those queries will still return data. But that data will be frozen for existing plans until an administrator migrates them to the Condition Builder.

Key developer actions for 2026:

1. Audit any queries hitting plan criteria columns in ANC_ABS_PLANS_F.
2. Identify which plans are still on Expression Builder by checking for legacy format markers in those columns.
3. Coordinate with functional teams to run the migration before the Expression Builder is fully removed.

ANC_PER_ABS_ENTRIES: The Primary Table in the Redwood Absence Management Schema Shifts

ANC_PER_ABS_ENTRIES is the transaction-level table for individual absence records. It holds the start date, end date, duration, and status for every absence event tied to a person.

The Release 26A Redwood Absence Management schema shifts bring one critical improvement to this table's behavior: a single absence entry can now handle future and past assignment shifts in a unified view. Previously, assignment changes often forced manual date-correction updates or split records. In 26A, the Redwood UI and the REST layer manage this natively, reducing the need for custom SQL workarounds.

For report writers, this means:

• Fewer orphaned or split absence records to reconcile in your queries.
• Audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) are now directly surfaced and queryable with greater reliability via the VBCS layer.
• EFFECTIVE_DATE filtering remains essential; do not drop it from your WHERE clauses.

This table is also the primary join point between person-level absence data and plan-level entitlements. Your cross-table queries will run through here before hitting the oracle hr tables for employment context.

Absence Types, Plans, and Reasons After Release 26A in Oracle Fusion HCM

Three reference tables define the configuration framework for every absence transaction in oracle fusion hcm: types, plans, and reasons. Each has a distinct role in the hcm data model, and each is touched by the 26A schema shifts in different ways.

ANC_ABS_TYPES_F defines what kind of absence an entry represents. In 26A, type-level qualification criteria now use the Condition Builder. Navigate to ANC_ABS_TYPES_F to review the column structure before writing any criteria-parsing queries.

ANC_ABS_PLANS_F is where accrual rules live. This is the most impacted table in the Release 26A Redwood Absence Management schema shifts. Plan criteria serialization has changed, and any reports that decoded Expression Builder output need to be reviewed against the new Condition Builder format.

ANC_ABS_REASONS_F is reference data for categorizing leave. Its schema is relatively stable in 26A, but its REST endpoint exposure has changed slightly to support Redwood lookup component behavior. See the full column list for ANC_ABS_REASONS_F to verify any lookup joins in your OTBI reports.

Each of these tables uses date-effective rows (the _F suffix convention in oracle cloud hcm). Always filter on EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. This is standard for oracle hcm tables in the ANC namespace, and 26A does not change that convention.

How Release 26A Redwood Absence Management Schema Shifts Affect Join Paths

The Release 26A Redwood Absence Management schema shifts do not break existing join paths. But they add complexity you need to account for in 2026 reporting builds.

Here is the standard join chain for absence reporting in oracle fusion hcm:

ANC_PER_ABS_ENTRIES (transaction level)
  JOIN ANC_ABS_TYPES_F ON ABSENCE_TYPE_ID (filter EFFECTIVE_DATE)
  JOIN ANC_ABS_PLANS_F ON PLAN_ID (filter EFFECTIVE_DATE)
  JOIN ANC_PER_PLAN_ENROLLMENTS ON PERSON_ID + PLAN_ID
  JOIN PER_ALL_PEOPLE_F ON PERSON_ID (filter EFFECTIVE_DATE)
  LEFT JOIN ANC_ABS_REASONS_F ON REASON_ID (filter EFFECTIVE_DATE)

This chain still works in 26A. However, there are two areas to watch:

• Plan criteria columns in ANC_ABS_PLANS_F: If your report surfaces plan criteria text or evaluates plan conditions, the serialization format has changed for new plans. Old plans remain in Expression Builder format until migrated.
• Audit column availability: The four new audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) are now more reliably available directly in the base tables via the VBCS-driven layer, which is useful for compliance reports.

Writing SQL Against the New Oracle HCM Tables Structure in 26A

Writing SQL against oracle hcm tables in the ANC namespace post-26A requires the same fundamentals as before, but with a few additions.

Here is a practical query template for pulling active absence entries with type and reason context in oracle cloud hcm:

SELECT
  pap.person_number,
  pap.full_name,
  ent.start_date,
  ent.end_date,
  ent.duration,
  ent.status,
  typ.name          AS absence_type,
  rsn.name          AS absence_reason,
  ent.creation_date,
  ent.created_by,
  ent.last_update_date,
  ent.last_updated_by
FROM
  anc_per_abs_entries     ent
  JOIN per_all_people_f   pap  ON ent.person_id = pap.person_id
                               AND TRUNC(SYSDATE) BETWEEN pap.effective_start_date AND pap.effective_end_date
  JOIN anc_abs_types_f    typ  ON ent.absence_type_id = typ.absence_type_id
                               AND TRUNC(SYSDATE) BETWEEN typ.effective_start_date AND typ.effective_end_date
  LEFT JOIN anc_abs_reasons_f rsn ON ent.reason_id = rsn.reason_id
                               AND TRUNC(SYSDATE) BETWEEN rsn.effective_start_date AND rsn.effective_end_date
WHERE
  ent.status = 'COMPLETED'
  AND ent.start_date >= ADD_MONTHS(TRUNC(SYSDATE,'YYYY'), -12)
ORDER BY
  pap.person_number, ent.start_date;

The four audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) in this query are now reliably populated for all entries created after the 26A Redwood migration is activated via the profile option.

Note the PER_ALL_PEOPLE_F join: this is standard across all oracle hr tables that touch person-level data. The date-effective filter is non-negotiable. Dropping it produces cross joins on historical rows and will inflate your result set severely.

PER_ALL_PEOPLE_F and Plan Enrollment Joins in the 26A Schema

PER_ALL_PEOPLE_F is the anchor for person identity across the entire oracle fusion hcm data model. In the context of the Release 26A Redwood Absence Management schema shifts, it shows up most prominently in two places.

First, in ANC_PER_PLAN_ENROLLMENTS. Every enrollment record links a PERSON_ID back to PER_ALL_PEOPLE_F via that key. The ANC_PER_PLAN_ENROLLMENTS table tells you which plan an employee is enrolled in and when that enrollment is effective. Joining this to PER_ALL_PEOPLE_F gives you named person context for any enrollment-level report.

Second, in absence entry queries. ANC_PER_ABS_ENTRIES stores PERSON_ID directly. Joining to PER_ALL_PEOPLE_F on that key, with a date-effective filter, gives you person name, person number, and any person-level attributes you need for absence reporting.

The join itself has not changed in 26A. But one practical caution: in oracle cloud hcm environments where the Redwood profile option is enabled, REST-layer caching for Absence pages can create short windows where UI-displayed data and directly queried data appear out of sync. For scheduled reports, always run against a refreshed data snapshot, not live UI cache.

PER_ALL_PEOPLE_F is one of the most referenced oracle hr tables in the entire HCM schema. If you are new to absence reporting, make this your starting join for any person-centric query before moving deeper into the ANC namespace.

OTBI Report Writers: Adapting to Release 26A Redwood Absence Management Schema Shifts

The Release 26A Redwood Absence Management schema shifts require OTBI report writers to check three things before publishing any absence-related analysis in 2026.

1. Subject Area availability. Oracle updates Absence Management subject areas to reflect Redwood-exposed columns. The four new audit columns are now available in the Workforce Management - Absence Real Time subject area. If your existing reports were built before 26A, rebuild the column list to pick up these additions.

2. Plan criteria filters. If any OTBI filter references plan criteria expressions from the old Expression Builder, those filters may return no data for new plans built post-26A. The Condition Builder stores criteria differently. Update those filters to use the new attribute paths.

3. Absence type and reason lookups. These are stable in the hcm data model, but verify that your OTBI joins through ANC_ABS_TYPES_F and ANC_ABS_REASONS_F still resolve correctly after the Redwood migration is activated. Minor REST endpoint changes can affect how OTBI resolves display labels for these reference tables.

Performance Considerations for Oracle Cloud HCM After the 26A Schema Shifts

Performance is a real concern in oracle cloud hcm after the Release 26A Redwood Absence Management schema shifts. Redwood page load times for Absence Management administrative pages have been measured at roughly 3.5x slower than the legacy Responsive UI in early 26A benchmarks.

For report writers and SQL developers, the performance implication is indirect but important: users experiencing slower Redwood UI pages are more likely to run batch reports during peak hours, increasing load on the reporting layer. Plan your scheduled reports accordingly.

For direct SQL performance against oracle hcm tables in the ANC namespace, the schema shifts themselves do not add query overhead. The tables have not been restructured in ways that break existing index usage. However, two practices will keep your queries efficient post-26A:

• Always filter on EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. Date-effective tables in the oracle fusion hcm schema accumulate historical rows rapidly. Without date filters, full table scans are likely.
• Avoid SELECT * from ANC_PER_ABS_ENTRIES in large environments. This table grows with every absence transaction. Select only the columns you need, and filter by date range and status upfront.

If your environment has enabled the ORA_ANC_ADMIN_ABSENCE_VBCS_UI_ENABLED profile option, be aware that the REST layer now mediates some data writes. For integration developers using direct DML against ANC_ tables, confirm with Oracle Support that your approach is still supported in 26A. The recommended path for real-time event-driven absence integrations in 2026 is HCM Atom Feeds, not direct table polling.

For environments supporting high-volume absence processing, such as large public sector or healthcare implementations, the 26A schema shifts may require tuning OTBI query plans that join across multiple ANC_ tables and PER_ALL_PEOPLE_F in a single report run.

Enabling the 26A Redwood Absence Schema: The Profile Option That Controls Everything

One profile option gates the entire Release 26A Redwood Absence Management schema shift behavior: ORA_ANC_ADMIN_ABSENCE_VBCS_UI_ENABLED.

Until this is enabled at site level, your environment stays on the legacy ADF-based Absence administrative pages. The Condition Builder does not activate. The four new audit columns do not surface. The unified assignment-shift handling in ANC_PER_ABS_ENTRIES does not apply.

This is the primary toggle. Set it before any 26A absence plan migration work begins. Confirm it is enabled before running any validation queries to check whether the new schema columns are populated.

Developers integrating with oracle cloud hcm via REST APIs should also verify that Absence REST endpoint versions are updated to the 26A-compatible versions after this profile option is enabled. Legacy REST calls to /hcmRestApi/resources for absence types and plans may return different response structures once the VBCS layer is active.

Conclusion

The Release 26A Redwood Absence Management schema shifts are not optional reading for oracle fusion hcm developers and report writers in 2026. They change how plan criteria are stored, how audit data is exposed, and how the VBCS layer mediates data between the UI and the ANC_ table namespace.

The core oracle hcm tables (ANC_PER_ABS_ENTRIES, ANC_ABS_TYPES_F, ANC_ABS_PLANS_F, ANC_PER_PLAN_ENROLLMENTS, and ANC_ABS_REASONS_F) remain your primary targets for absence reporting and SQL development. The join to PER_ALL_PEOPLE_F is unchanged. Date-effective filtering is still mandatory.

What has changed is the plan criteria format (Condition Builder replaces Expression Builder), the availability of four new audit columns, and the profile option requirement that activates all of it. Audit your existing queries against the impacted oracle hr tables now, before legacy Expression Builder plans become an unmaintainable blocker.

Need column-level detail on any ANC_ table in the oracle cloud hcm schema? Search across 35,000+ oracle hcm tables and 1.2M+ columns at hcm-tables.com. Faster than Oracle docs. No nested dropdowns. Just the schema info you need.