Redwood Recruiting: the ESS and OSCS index ingest jobs must all succeed, or the data won't load

# Fix of the Day #25: Redwood Recruiting: the ESS and OSCS index ingest jobs must all succeed, or the data won't load

Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #25. Start from Fix #1 to follow the series in order.

Moving Recruiting to Redwood is not just a switch you turn on. The Redwood pages read much of their data from Oracle Search (OSCS, Oracle Search Cloud Service), and that search data has to be built by a set of scheduled processes. During our Recruiting Redwood setup, the lesson was simple and strict: every one of those ESS jobs has to finish with Succeeded. If even one ends in Warning or Error, the data does not load, and the Redwood pages show an incomplete picture.

The symptom

We submitted the ESS jobs for the Recruiting Redwood setup. Some completed. Some ended in Warning or Error. Others sat in Wait or Hold and never really started.

From the outside it looked like the setup had run. But the data was not there in Redwood: requisitions, candidates and lists of values were missing or incomplete. It is easy to look at a list of processes, see mostly green, and move on. That is the trap. A partial run is not a successful run.

Why it happens

These jobs depend on each other. One job builds or loads index data that the next one needs. If a job ends in Warning or Error, the index it was meant to build is incomplete, and anything that runs after it works from that gap.

Jobs stuck in Wait or Hold cause a different problem. Recurring indexing jobs and old duplicate requests keep running in the background. They compete with the full reload you are trying to do, or run on top of it at the wrong moment.

So a clean result needs two things: a clear queue before you start, and every job ending in Succeeded.

Before you start

• You need the FND_MANAGE_SCHEDULED_JOB_DEFINITION_PRIV privilege to submit the OSCS ingest job. It comes with the Application Administrator and Application Developer job roles.
• If you use the Redwood requisition and offer lists of values backed by Oracle Search, enable their profile options first: ORA_PER_ORACLE_SEARCH_WORKERSLOV_ENABLED, ORA_PER_ORACLE_SEARCH_POSITIONSLOV_ENABLED, ORA_PER_ORACLE_SEARCH_DEPARTMENTSLOV_ENABLED, ORA_PER_ORACLE_SEARCH_LOCATIONSLOV_ENABLED and ORA_PER_ORACLE_SEARCH_JOBSLOV_ENABLED.
• If you use advanced job application filters, enable ORA_IRC_JA_ORACLE_SEARCH_ENABLED. Without it, the fa-hcm-jobapplication ingest fails with "Index not enabled".

The ESS jobs we ran, in order

Step 1: Stop and clear the queue

1. In Scheduled Processes, stop anything still Running for Recruiting search.
2. Cancel the recurring jobs Maintain Candidates and Job Requisitions for Search and Index Candidate Attachments.
3. Search by status for Hold and for Wait, and cancel every request you find.
4. Search once more and confirm nothing is left running, waiting or on hold.

Step 2: Reload the Recruiting search data (one at a time, each must succeed)

1. Load and Index Master Geography Hierarchy, with no parameters.
2. Load and Index Job Requisitions, indexing mode Drop and Recreate Index.
3. Load and Index Candidates, indexing mode Drop and Recreate Index.
4. Index Job Summary for Each Requisition, Full mode (needed for Smart Search and Career Coach search).

Step 3: OSCS index ingest

Job name: ESS job to create index definition and perform initial ingest to OSCS. Submit it once for each index, entering the index in the Index Name to Reingest field. Submit them one by one, and wait for each to succeed before the next. Never leave the field blank, or it runs for every predefined index.

1. fa-hcm-savedsearch
2. fa-hcm-requisition
3. fa-hcm-jobapplication (only if advanced job application filters are enabled)
4. fa-hcm-irc-hiring-events (if you use hiring events)
5. fa-hcm-irc-messages (if you use the Redwood Message Center; run once, do not schedule it)
6. For the Redwood requisition and offer lists of values: fa-hcm-person, fa-hcm-position, fa-hcm-organization, fa-hcm-location and fa-hcm-job

Step 4: Restart the incremental jobs

1. Maintain Candidates and Job Requisitions for Search, every 15 minutes.
2. Index Candidate Attachments, every 15 minutes.
3. Index Job Summary for Each Requisition, Incremental mode.

How I fixed it

1. I stopped all running Recruiting search jobs and cancelled every request in Hold or Wait.
2. I confirmed the queue was clear before submitting anything.
3. I ran the jobs above one at a time, in order.
4. After each job, I checked the status. If it ended in Warning or Error, I opened the log, fixed the cause, and reran it before submitting the next one.
5. When every job showed Succeeded, I restarted the recurring jobs.
6. I checked the Redwood Recruiting pages, the requisition and candidate searches and the lists of values, and confirmed the data had loaded.

How to avoid it next time

• Clear the queue first. Stop anything running, and cancel everything in Hold or Wait.
• Treat Warning as a failure for setup jobs. Read the log every time.
• Run the initial OSCS ingest by hand, once per index. Oracle advises against scheduling it.
• Keep a checklist of the jobs with a status column, and tick each one only when it shows Succeeded.
• Rerun the relevant jobs after quarterly updates and after a production-to-test refresh, following Oracle's guidance for your release.
• After the last job, check the data in the Redwood pages, not just the job statuses.

Recruiting data depends on search indexes more than most people expect. In Fix #7, jobs were missing from the career site until the search index was rebuilt. Different symptom, same lesson: check the processes behind the page.

Key takeaway

For a Recruiting Redwood setup, every ESS and OSCS ingest job must end in Succeeded. Stop running jobs, cancel anything in Hold or Wait, then run the jobs one at a time in order and fix every warning or error before moving on.

Meeramaheswari Annadurai, Oracle HCM & Enterprise AI. More at meera2k10.github.io/enterprise-ai

```

Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #20. Start from Fix #1 to follow the series in order.

The goals were there. The goal plan was set up. Employees had their goals. But when users tried to view employee goals, they could not see them. The setup was not the problem. The role was. The fix was one privilege: HRG_VIEW_PERFORMANCE_GOALS_PRIV.

The symptom

Users who needed to view employee goals could not see them. Other parts of the worker's record opened normally, so it did not look like a general access problem.

There was no clear error to point at. When a page or a section simply does not show, it is easy to spend time on the goal plan, eligibility and dates first. I had covered those checks in Fix #19: mass-assigned goals not showing for employees. This time all of them were fine.

Why it happens

In Oracle Fusion, what a user can see and do comes from privileges. Privileges are grouped into duty roles, and duty roles are grouped into the job and abstract roles you assign to users. If the role is missing the privilege that a page or action needs, the user does not get it, even when the data is there and correct.

Viewing performance goals is controlled by its own privilege, HRG_VIEW_PERFORMANCE_GOALS_PRIV. If a user's role does not include it, they cannot view employee goals.

This is especially easy to miss with custom roles. Many implementations copy seeded roles and then maintain the copies. When Oracle adds or changes privileges in later updates, or when Redwood pages need privileges the old pages did not, the custom copies do not pick them up by themselves. The role that worked last year can quietly fall short this year.

How I fixed it

1. I confirmed the data side first: the goal plan, review period and the employee's goals were all in place. That ruled out setup.
2. I compared a user who could not see the goals with one who could, and looked at the roles each of them had.
3. I reviewed the roles in the Security Console and found that the privilege to view performance goals, HRG_VIEW_PERFORMANCE_GOALS_PRIV, was missing from the role the affected users relied on.
4. I added HRG_VIEW_PERFORMANCE_GOALS_PRIV to the custom role, so every user with that role got it, rather than fixing one user at a time.
5. I asked a test user to sign out and sign back in, so the updated role was picked up.
6. I confirmed the user could now view employee goals, then checked with a few more users who had the same role.

How to avoid it next time

• When data is there but a user cannot see it, check the role and its privileges before reworking setup.
• Compare a user who can see the data with one who cannot. The difference in roles usually points straight at the gap.
• After each quarterly update, and during any Redwood move, review your custom roles against the seeded ones for new privileges.
• Add privileges at the role level, not as one-off fixes, so everyone in the same role gets the same access.
• Test every key page with real role combinations, not only with an administrator who can see everything.

Key takeaway

If users cannot view employee goals and the goal setup is correct, check their role. Adding HRG_VIEW_PERFORMANCE_GOALS_PRIV fixed it for me.

Next in the series: the same kind of gap in the Employee and Manager Concierge agent apps, and fixing them by adding the missed privileges.

Meeramaheswari Annadurai, Oracle HCM & Enterprise AI. More at meera2k10.github.io/enterprise-ai

Recruiting: jobs not visible on the career site

# Fix of the Day #7: Recruiting: jobs not visible on the career site

Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #7. Start from Fix #1 to follow the series in order.

A recruiter publishes a job. The requisition says it is posted. But when a candidate opens the career site, the job is not there. This one causes a lot of back and forth between recruiters and the HCM team, because everything in the requisition looks correct. In my case the setup was fine. The search index behind the career site was not.

The symptom

Published requisitions were not showing on the career site. Recruiters could see them in the requisition list. The status looked right. The posting looked right. Candidates searching the career site simply could not find them.

There was no error message anywhere. That is what makes this kind of issue confusing. Nothing fails. The job just does not appear.

Why it happens

The career site does not read requisitions directly from the transaction tables every time a candidate searches. It relies on a search index. In Oracle Recruiting Cloud, that search is powered by Oracle Search Cloud Service, often called OSCS.

When a requisition is published, it needs to be picked up by that index before candidates can find it. If the index is out of step with the data, the career site shows an old picture. Jobs that are live in the application can still be missing from search results.

So there are two separate things to check. First, is the requisition really eligible to show on the career site? Second, has the search index caught up with it? In my case the first was fine. The fix needed an OSCS index rebuild.

How I fixed it

1. I took a few specific requisitions that were missing and used them as test cases for the whole investigation.
2. I checked each requisition's status and confirmed it was open and published, not just approved or saved.
3. I checked the posting details: that it was posted to the right career site, internal or external, and that the posting start and end dates covered today.
4. I searched the career site for those jobs using the job title and the requisition number, and confirmed they were still missing.
5. With the requisition setup confirmed, I treated it as a search index problem rather than a data problem.
6. I ran the OSCS index rebuild for recruiting through the scheduled processes.
7. Once the process completed, I searched the career site again. The missing jobs now appeared.
8. I asked the recruiters to confirm a few more of their recent postings were visible.

How to avoid it next time

• Check the requisition first. Status, career site and posting dates explain many missing jobs before you touch the index.
• If the setup is correct and jobs are still missing, suspect the search index early instead of reworking requisitions.
• Re-check career site search after quarterly updates, bulk requisition loads and career site configuration changes.
• Agree with recruiters on a simple first check: search by requisition number on the career site before raising a ticket.
• Keep a short runbook entry for the index rebuild, so anyone on the support team can run it and verify the result.

Key takeaway

If a published requisition is not visible on the career site and the posting setup is correct, the search index is the likely gap. Rebuilding the OSCS index brought the jobs back for me.

Next in the series: loading learning completions with HDL, and why gaps in the payroll calendar blocked backdated records.

Meeramaheswari Annadurai, Oracle HCM & Enterprise AI. More at meera2k10.github.io/enterprise-ai

```

# Fix of the Day #5: Learning: SCORM content failing to launch in Redwood Status: draft Title: Learning: SCORM content failing to launch in Redwood Labels: Oracle HCM, Fix of the Day, Learning Blogger: New Post → HTML view → paste the HTML below. ```html

Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #5. Start from Fix #1 to follow the series in order.

Learning was one of the phases in our Redwood rollout. Most of it went smoothly. Then learners started reporting that some SCORM courses would not launch in the new Redwood Learning pages. The course was there. The enrollment was there. The content just would not play. This post walks through the checks I use when SCORM content fails in Redwood.

The symptom

A learner opens the course and clicks to start the e-learning. Instead of the content, they get a blank frame, a window that never loads, or a player that opens and then stops. Other courses on the same page may work fine. That pattern matters. It tells you the problem is usually tied to the content or the way it is launched, not to the learner's enrollment.

Why it happens

A SCORM course is a package. It has a manifest that tells the player where to start and how to talk to the learning system. Fusion Learning hosts the package and launches it through its content player. The content then sends progress and status back to Fusion.

That chain has several weak points. The package can be built in a way the player does not expect. The player settings on the activity can open the content in a way the browser blocks. And the browser itself can stop the content from loading, for example through pop-up blocking or rules about content coming from a different domain.

Redwood changes the page around the player. Content that behaved under the older pages can react differently when the launch flow changes. So after a Redwood move, it is worth checking each link in the chain again, not assuming the content is still fine because it worked before.

How I fixed it

1. I confirmed the scope first. Was it one course, one content vendor, or all SCORM content? Was it every learner or only some? This narrowed things down quickly.
2. I tried the same course in a different browser and in a private window. This rules out cached files and browser extensions.
3. I checked whether the browser was blocking a pop-up or new window when the content launched. Allowing pop-ups for the Fusion site is a common fix.
4. I looked at the browser developer console while launching the course. Errors about blocked frames or cross-domain access point straight to a launch or hosting problem.
5. I reviewed the package itself: the manifest at the root of the zip, the SCORM version it was built for, and the launch file it points to. A package zipped one folder too deep is a classic cause.
6. I reviewed the player and launch settings on the learning activity, such as whether it opens in a new window or in the page.
7. Where the package was the problem, I had it republished from the authoring tool, uploaded it again, and retested with a test learner before releasing it.

How to avoid it next time

• Test a sample of SCORM courses from each content vendor as part of Redwood testing, not just the page layout.
• Keep a short packaging standard for authors: manifest at the root, agreed SCORM version, tested export settings.
• Agree browser settings with your IT team, including pop-ups for the Fusion domain, before go-live.
• Always check completion tracking too. A course that launches but never reports status is the next ticket waiting to happen.
• Keep a test learner account in each environment for quick launch checks after quarterly patches.

Key takeaway

When SCORM content fails in Redwood, work through the chain in order: browser, launch settings, then the package. Most failures sit in one of those three places.

Next in the series: Absence approvals sending FYI notifications to the wrong people, and how OR versus AND in an approval rule changes who gets notified.

Meeramaheswari Annadurai, Oracle HCM & Enterprise AI. More at meera2k10.github.io/enterprise-ai

```

Real issues from implementations and a Redwood rollout

 Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #2. Start from Fix #1 to follow the series in order.

Quarterly patches are part of life on Oracle Fusion. Most of the time they land quietly. This one did not. After the 26A patch, I opened a Visual Builder Studio workspace to continue a Redwood page extension, and the Page Designer canvas simply would not render. This post covers what I saw, what caused it, and the fix that worked.

The symptom

The workspace opened. The project files were all there. I could browse the page structure and open the source view. But the design canvas in Page Designer stayed blank or kept spinning. I could not see or select any components on the page, so I could not make visual changes at all.

Nothing in my extension had changed. The same workspace had worked fine before the patch. That was the first clue that the problem was not in my code.

Why it happens

A VB Studio workspace is not just a copy of your source files. It also holds metadata about the runtime it is built against. That includes the Runtime Dependency information, which tells the designer which version of the Fusion application components and Redwood libraries to load.

When Oracle applies a quarterly patch, the underlying Fusion runtime moves to a new version. An older workspace can keep pointing at the old runtime details. The designer then tries to load components that no longer match what the environment is serving. The result is a canvas that cannot draw the page.

In my case, the Runtime Dependency metadata in the workspace was stale after 26A. The project itself was fine. The workspace was the problem.

How I fixed it

1. I made sure every change I cared about was committed and pushed to the project's Git repository. This step matters. Deleting a workspace removes anything that only lives there.
2. I checked the repository to confirm the latest commit had my recent changes.
3. I deleted the affected workspace from VB Studio.
4. I created a fresh workspace from the same project and branch.
5. I opened the extension in the new workspace and let it load against the current runtime.
6. I opened the Redwood page in Page Designer. The canvas rendered normally, and the components were selectable again.
7. I previewed the page and ran a quick test of the extension to confirm nothing else had shifted with the patch.

The whole fix took less time than I had already spent trying to refresh the browser and clear the cache. Those steps did not help, because the stale data was inside the workspace, not in the browser.

How to avoid it next time

• Commit and push your work before every quarterly patch window. A clean repository makes recreating a workspace safe and quick.
• Treat workspaces as disposable. The project and repository are the source of truth.
• After each patch, open your key Redwood extensions in Page Designer early, before anyone needs an urgent change.
• If the canvas fails after a patch, check the workspace before you start debugging your own code.
• Read the quarterly update notes for VB Studio and Redwood changes, so you know what moved underneath you.

Key takeaway

When the VB Studio canvas breaks right after a quarterly patch, suspect stale workspace metadata first. Push your changes, delete the workspace, and recreate it from the project.

Next in the series: Redwood payslip generation fails with "mainTemplPath is null", and how a catalog path mismatch caused it.

More at meera2k10.github.io/enterprise-ai

Redwood: VB Studio canvas won't load after the 26A patch

 

The symptom

After extending a Redwood page in VB Studio, the Submit button appeared exactly where it should. It looked right, it was enabled, and clicking it did nothing. There was no error message, no spinner and no transaction created. Users assumed the system was slow and clicked again and again.

Why it happens

In Redwood pages built on Oracle JET, a button is only a visual component until something is wired to its click event. The button was placed on the page, but it had no ojAction event binding, so no action chain was connected to it. JET fires the event, and nothing is listening.

This is easy to miss when you copy a button from another page or rebuild a layout. The markup comes across, but the event mapping doesn't.

How I fixed it

1. Open the page in VB Studio and select the button in the Page Designer.
2. Go to the button's Events tab. If ojAction isn't listed, that's the problem.
3. Add a new event for ojAction and attach it to the action chain that submits the transaction. Create one if needed, or reuse the existing submit chain from the original page.
4. In the page source, confirm the button now has on-oj-action="[[$listeners.yourSubmitListener]]".
5. Preview, test the full submit, then publish the extension.

How to avoid it next time

• After copying any button, check its Events tab before you test anything else.
• Add "every action button has an ojAction listener" to your Redwood extension checklist.
• If a button "does nothing" with no error, check the event binding before suspecting security or the REST service.

Key takeaway

In Redwood, a button you can see is not a button that works. A silent failure with no error almost always means the event isn't wired, not that the back end failed.

Next in the series: a VB Studio canvas that won't load after the 26A patch, and why deleting the workspace was the fix.

How I used Oracle AI Agent Studio Agent Apps to turn reactive HR chat agents into proactive Employee and Manager workspaces.

Agents that wait to be asked

Our HCM Agents already answer HR questions through Ask Oracle. But a chat agent only helps when someone thinks to ask. Open onboarding tasks, overdue courses, leave awaiting approval and who on the team is off next month were spread across Journeys, Learning, Absence and the notifications inbox.

So I tried a different approach: let the AI gather everything first and tell people where they stand.

Two workspaces, one Home page

• Employee Concierge: what needs your attention, what is waiting on someone else, and how your leave has been used this year.
• Manager Concierge: a team snapshot, priority actions, upcoming absences, plus talent, pay and retention risk.

Both sit next to the existing agents on the Fusion Home page: Home > Create a Page Entry > Place your Apps icon.

How it works

Step 1: Employee, start with the AI summary

The workspace opens with a plain-English summary of where you stand. Needs your attention lists the courses and journey tasks waiting on you. In progress shows requests waiting on someone else, such as leave awaiting approval.

Step 2: Employee, check your leave

Scroll down for your monthly leave pattern and leave by absence type for the year, with key insights in days or hours.

Step 3: Manager, get the team snapshot

The AI writes a short narrative of the team: size, roles, grades, tenure and location. Alongside it are priority actions, a one-click reminder to the team, pending items and upcoming absences.

Step 4: Manager, go deeper on talent and pay

Annual pay and retention risk for each person, plus performance rating and impact of loss. Any card expands to full screen.

Design choices that mattered

1. Summary first. One AI-written paragraph tells people where they stand before they read any table.
2. An overview, not a new transaction screen. Leave, learning and journeys are still done in their standard Fusion pages.
3. Same security as HCM. Employees see only their own data; managers see only their direct team.
4. Live data. The workspace reads the latest HCM data each time it opens.

What's done

Both workspaces are built, tested and documented with a quick-reference guide for employees and managers, ready for rollout.

What I learned

AI in HR isn't only about answering questions. It is about deciding what someone needs to see today and saying it in one sentence. The question changes from "what can I ask?" to "what should I do next?".

If you're building with Oracle AI Agent Studio, I'd love to hear how you're approaching Agent Apps. Leave a comment below.

See the full walkthrough on my site: Employee & Manager Concierge Workspaces.

Names, organisation, pay and location details in the screenshots are fictional (AI-generated) for illustration only.

Meeramaheswari Annadurai: Business Applications Principal, Oracle Fusion HCM and Enterprise AI