As Oracle Fusion applications continue to move toward the Redwood user experience, search is becoming a more important part of how users navigate and interact with enterprise data. Oracle Search is designed to provide a faster, more intuitive search experience across Fusion applications by using indexed data instead of querying the full transactional database each time a user performs a search. Oracle describes it as a web-style search capability built directly into Oracle Fusion. Compared with traditional database search, Oracle Search supports optimized indexes, fuzzy and phonetic matching, precomputed security and intelligent relevance ranking. For organizations adopting Redwood across HCM, SCM, CX and Finance, understanding how Oracle Search works — and how to configure it correctly — is becoming essential. 

What Is Oracle Search? 

Oracle Search is the search mechanism used across many Redwood pages in Oracle Fusion applications. Instead of searching directly against the transactional database each time a user enters a keyword, Oracle Search relies on dedicated indexes containing searchable data. This approach can improve scalability and provide a more modern search experience. 

Traditional database searches may depend on exact matches and runtime security evaluation, while Oracle Search introduces capabilities such as: 

  • Fuzzy matching 
  • Phonetic matching 
  • Precomputed access control 
  • Optimized search indexes 
  • Intelligent relevance ranking 

The central concept is straightforward: searchable business data is copied into an index optimized for search. When users search from a Redwood page, Oracle searches that index rather than repeatedly scanning the entire application database. 

Why Oracle Search Matters for Redwood 

Oracle specifically identifies Oracle Search as the search mechanism used by Redwood pages across Fusion SaaS applications. 

The presentation references areas including: 

  • Order Management 
  • Cost Management 
  • Manufacturing 
  • Maintenance 
  • Quality Management 
  • Planning 
  • Procurement 
  • Product Management 
  • Inventory Management 
  • Global HR 
  • Talent 
  • Recruiting 
  • Compensation 
  • Benefits 
  • Payroll 
  • Absence 
  • Time and Labor 

This means Oracle Search should not be viewed as an isolated technical feature. For many organizations, it is part of the underlying architecture supporting Redwood adoption. If search indexes, access-control lists or profile options are not configured correctly, users may enable a Redwood page but still find that expected records do not appear. That makes Oracle Search setup an important component of Redwood readiness. 

Fuzzy Search Improves the User Experience 

One of the major benefits of Oracle Search is fuzzy searching. Oracle Search can return similar matches rather than requiring an exact value. For example, Oracle’s presentation explains that a search for “Jon” can also return “John,” while “Smyth” can return “Smith.” This type of matching is useful because users do not always know the exact spelling or stored value of a record. In practical scenarios, fuzzy matching can reduce failed searches and help users locate records more quickly. This becomes especially valuable when working with large employee, supplier, order, asset or product populations. 

Multilingual Search Support 

Oracle Search can also support multiple enabled languages. The search index can work with multiple languages configured within the Oracle Fusion environment. For global organizations, this can improve the search experience across regional teams and multilingual deployments. Rather than designing search around one language or naming convention, organizations can support a broader set of user requirements. 

Faceted Search Makes Large Data Sets Easier to Navigate 

Another important Oracle Search capability is faceted search. Faceted search allows users to apply filters while also viewing aggregation counts. This provides a more predictable search experience because users can understand approximately how many records will remain after applying specific filters. Oracle provides an example of combining dimensions such as department and location to narrow the result set. This becomes particularly useful with large data populations. Instead of reviewing hundreds or thousands of results, users can progressively narrow records using relevant business attributes. 

For example, an organization could combine: 

  • Business unit 
  • Location 
  • Status 
  • Department 
  • Job 
  • Category 

The result is a search process that feels closer to modern consumer and ecommerce applications. 

Saved Searches Can Improve User Productivity 

Oracle also highlights the ability to save frequently used searches. Saved searches provide quicker access to commonly used criteria and can help users reduce repetitive filtering. A user who repeatedly searches for the same employee group, procurement records or operational transactions can reuse predefined search criteria instead of rebuilding the search each time. Oracle recommends combining multiple search techniques — keyword search, filtering and saved searches — to improve efficiency. 

How Oracle Search Indexing Works 

The index and ingestion process is one of the most important concepts to understand. Searchable application data must first be copied into a functional search index. Oracle provides examples such as a person index where person-related data is ingested into the fa-hcm-person functional index. There are two important ingestion concepts. 

Initial ingestion 

Initial ingestion copies searchable data from the Oracle Fusion database into the search index. This is part of the initial Oracle Search setup. 

Incremental ingestion 

Once the initial data has been loaded, new or changed data can be copied into the index incrementally during the application’s normal lifecycle. Oracle notes that this incremental process is transparent to end users and does not require additional manual action. This distinction is important because organizations should not repeatedly schedule full initial ingestion jobs as part of normal operations. 

Data Security Through Access Control Lists 

Search performance is only useful if users see the correct data. Oracle Search handles data security using Access Control Lists, or ACLs. Oracle describes an ACL as the computed list of records a particular user is permitted to access. Every user must have their ACL calculated before secured Oracle Search results can be returned correctly. The initial ACL ingestion is therefore a required setup step. After initial configuration, scheduled ACL processes keep access-control information current as user roles, security assignments and business data change. 

The Four Core Steps for Setting Up Oracle Search 

Oracle describes a four-step core setup process: 

  • Enable the required Oracle Search profile options. 
  • Perform the initial functional-index ingestion. 
  • Configure data security. 
  • Enable applicable functional or module-specific profile options. 

The sequence matters. Oracle specifically warns that enabling module-specific profile options before completing the required search setup may result in no search results being returned. For implementation teams, this means Oracle Search should be treated as a structured configuration activity rather than a single toggle. 

Step 1: Enable Oracle Search Profile Options 

The first step involves enabling the required search-related profile options. Oracle’s presentation provides examples including search framework, HCM search and user-login event publication profile options. These profile options help activate the underlying Oracle Search framework. The exact options may depend on the module being configured, so Oracle recommends consulting the relevant product documentation before making changes. This is especially important in large Fusion environments where several modules may adopt Oracle Search at different stages. 

Step 2: Perform Functional Index Initial Ingestion 

Once Oracle Search has been enabled, the required functional indexes need to be created and populated. Oracle identifies the ESS job used to create the index definition and perform the initial ingest to Oracle Search Cloud Service. The presentation provides examples of indexes across multiple application areas. 

For SCM and related functionality, examples include indexes for: 

  • Assets 
  • Work definitions 
  • Recalls 
  • Customer claims 
  • Customer programs 
  • Sales orders 
  • Sales order lines 
  • Expected receipts 
  • Receiving transactions 

Oracle also lists functional indexes for HCM, Procurement, Projects, Financials, CX and approvals. Only the indexes required for the relevant functionality should be initialized. 

Step 3: Configure Data Security and ACL Ingestion 

After the functional indexes have been created, the access-control index must be initialized. Oracle explains that initial ACL ingestion creates the required ACL index and populates it with access-control information for users. This setup should normally be completed only once during the initial Oracle Search data-security configuration. Afterward, incremental ACL processes should be scheduled to keep security information current. 

Oracle’s recommended examples include: 

  • Compute Users ACL by Event: every 15–60 minutes 
  • Compute Users ACL for logged-in users: every 30–120 minutes 
  • Compute Users with Large ACL: once daily 

Oracle specifically advises against scheduling Compute Users ACL for All Users as a routine process. 

Step 4: Enable Module-Specific Search Options 

Some Redwood capabilities require additional module-specific Oracle Search profile options. 

Oracle’s presentation provides examples across areas such as: 

  • Global Human Resources 
  • Learning 
  • Workforce Management 
  • Profile Management 
  • Journeys 

These profile options should be enabled only after the underlying Oracle Search setup has been completed. Enabling a feature before its search index and ACL configuration are ready can result in users opening the Redwood page but seeing no search results. 

Oracle Search Best Practice: Follow the Setup Sequence 

The most important implementation principle is to follow the required sequence. 

Oracle summarizes the process as: 

Profile options → functional indexes → ACL/security setup → module-specific enablement. 

Initial functional ingestion should be completed only for the required indexes, and those jobs should finish before moving to subsequent configuration steps. This sequence reduces the risk of incomplete search experiences. For large Oracle environments, it is useful to document each module’s required index, profile option and security dependency before enabling the corresponding Redwood functionality. 

Business-as-Usual ACL Maintenance 

After Oracle Search has been successfully configured, attention shifts from setup to ongoing maintenance. Oracle recommends keeping the search and ACL indexes healthy through regular incremental ACL processes. For business-as-usual operation, Oracle highlights the importance of keeping the user login event publication setting active and scheduling the relevant ACL processes. This ensures that access changes are reflected in search results without repeatedly rebuilding the entire ACL index. 

What to Do When Enabling Oracle Search for an Additional Module 

A common scenario is that Oracle Search is already configured for one module and a company later introduces search for another. In this case, Oracle does not recommend recreating the ACL index from scratch. Instead, after ingesting the new functional index, organizations can compute ACL information for all users so they receive access information for the newly introduced index. The presentation provides an example where an organization is already using a person index and then adds Journeys. After completing the initial ingestion for Journeys, ACL computation should be run for all users — computation only, rather than recreating the ACL index. 

Best Practice After a P2T Refresh 

Oracle provides specific guidance for Production-to-Test, or P2T, refreshes. Following a P2T, Oracle Search should be treated similarly to a new initial setup for the target environment. Relevant functional indexes need to be re-ingested, and ACL data should be recreated or recomputed appropriately. Oracle also recommends running Compute Users ACL for the All Users population on the target environment after P2T. This is one of the scenarios where an all-users ACL computation is appropriate. 

What to Do After Major Security Role Changes 

Search security depends heavily on role assignments. If an organization changes a role that affects a large percentage of users — such as a broad employee or line-manager role — Oracle recommends recalculating ACL information across the affected user population. Oracle advises stopping incremental jobs temporarily, performing the all-users ACL computation and then resuming incremental processing. For role changes affecting only a small number of users, Oracle suggests computing ACL information for those individuals rather than recalculating security for the full population. This is a more efficient approach and avoids unnecessary system processing. 

Major Reorganizations and Mergers 

Organizational restructuring can have a significant impact on data security. During events such as major reorganizations, mergers or acquisitions, a large number of security relationships may change at the same time. Oracle recommends refreshing the relevant functional and ACL information, pausing incremental schedules while the broader ACL computation takes place, and then resuming incremental processing afterward. This helps ensure that Oracle Search reflects the new organizational security structure. 

Do: Confirm ACL Refresh Jobs Are Scheduled 

One of Oracle’s simplest recommendations is also one of the most important: 

Always verify that ACL refresh jobs are scheduled. 

A search index can contain current business data while still returning incorrect or incomplete results if the security index is outdated. Monitoring ACL schedules should therefore become part of normal Oracle Search operational support. 

Do: Perform Health Checks on Functional Indexes 

Oracle also recommends performing health checks on functional-index ingestion using diagnostic reports. The presentation notes that diagnostic reports are available for areas such as person data, Journeys and work structures. 

These diagnostics can help administrators identify: 

  • Incomplete ingestion 
  • Missing records 
  • Indexing failures 
  • Search discrepancies 
  • Synchronization issues 

This is particularly useful when users report that data exists in Fusion but cannot be found through the Redwood search experience. 

Don’t Schedule Functional Index Initial Ingestion 

Oracle specifically warns administrators not to schedule functional-index ingestion jobs as recurring processes. Initial ingestion is not designed as a routine refresh mechanism. Scheduling repeated initial ingestion consumes system resources unnecessarily. Incremental ingestion is designed to keep the search index current during normal application operation. 

Don’t Use All-Users ACL Computation as a Routine Refresh Job 

Another important warning is not to schedule Compute Users ACL with All Users as a replacement for normal incremental refresh processes. The all-users computation is appropriate in specific scenarios such as major security changes, a new functional index or P2T. For normal operations, incremental ACL processes should be used. This helps maintain security without creating unnecessary processing load. 

Don’t Re-run Initial ACL Ingestion if the ACL Index Already Exists 

One of the most important technical warnings in Oracle’s presentation concerns initial ACL ingestion. Oracle states that administrators should not run the initial ACL ingestion process if the ACL index already exists. Doing so can wipe out the existing ACL index. Until ACL data is recomputed, end users may stop receiving search results. 

This is why administrators should understand the difference between: 

  • Creating the ACL index 
  • Recomputing ACL data 
  • Running incremental ACL refreshes 

Using the wrong process can disrupt search availability. 

Don’t Manually Re-ingest Indexes During Every Release Upgrade 

Oracle also advises against manually running initial ingestion of functional indexes as part of every release upgrade. Oracle states that an automated process handles index re-ingestion when changes to index structure require it. If an index has not changed, there is no need to rebuild it after each quarterly upgrade. Oracle gives the same guidance for ACL ingestion: initial ACL ingestion should not be run simply because a Fusion release upgrade has occurred. This helps avoid unnecessary work and reduces the risk of disrupting an otherwise healthy Oracle Search environment. 

Oracle Search During Quarterly Upgrades 

Oracle’s scenario guidance explains that index-structure changes introduced through quarterly releases are handled automatically. Where an index requires rebuilding, the relevant process manages that work. If there are no structural changes to an index, administrators do not need to perform a new full ingestion. Oracle also recommends leaving normal business-as-usual ACL schedules in place. This means quarterly maintenance should focus on validation rather than automatically rebuilding every search component. 

Public Worker Access 

Oracle Search also continues to evolve from a security perspective. The presentation highlights Public Worker Access, introduced as generally available in the 25C update. This capability is designed to control access to search results for public-person searches. Oracle describes it as an enterprise-wide setting that works alongside existing public-person security profiles rather than replacing them. The capability provides selected security criteria designed to support common public-person search requirements. 

Public Worker Access Enhancements 

Oracle’s roadmap identifies further Public Worker Access enhancements for the 26A update. 

The presentation lists: 

  • Multiple Public Worker Access configurations 
  • Association of configurations with roles 
  • Additional security criteria 
  • An advanced condition-builder mode 

These enhancements would provide organizations with more flexibility over how public search visibility is controlled for different user populations. As with all roadmap content, Oracle’s safe-harbor statement applies, meaning development plans and timing may change. 

Common Oracle Search Problems to Watch For 

Many Oracle Search problems are likely to come from configuration rather than the search interface itself. 

Typical areas to investigate include: 

  • Required profile options not enabled 
  • Functional index not initially ingested 
  • Incorrect index selected 
  • Initial ACL ingestion not completed 
  • ACL refresh processes not scheduled 
  • User security not recomputed after role changes 
  • Functional profile options enabled too early 
  • Search configuration not rebuilt after P2T 
  • Unnecessary initial ingestion jobs consuming resources 

A structured troubleshooting approach should therefore review indexing, security and feature enablement separately. 

Why Oracle Search Is Important for SCM 

Oracle’s presentation includes several SCM-related indexes and identifies Oracle Search as the Redwood search mechanism for modules such as Procurement, Product Management, Inventory, Order Management, Manufacturing, Maintenance and Quality. For SCM organizations, this makes Oracle Search an important part of the user experience. 

Examples include searching for: 

  • Assets 
  • Work definitions 
  • Sales orders 
  • Receiving transactions 
  • Expected receipts 
  • Procurement records 
  • Product data 

If indexes and ACLs are properly maintained, users can access these records faster through Redwood search experiences. 

How NexInfo Helps with Oracle Search and Redwood Readiness 

NexInfo helps organizations plan, configure and optimize Oracle Fusion applications as they transition toward Redwood. 

For Oracle Search, NexInfo can support: 

  • Oracle Search readiness assessment 
  • Redwood search dependency analysis 
  • Search profile-option review 
  • Functional-index configuration 
  • Initial index-ingestion planning 
  • ACL and data-security setup 
  • Incremental ACL job scheduling 
  • Search diagnostic reviews 
  • P2T Oracle Search validation 
  • Quarterly upgrade readiness 
  • Security-role change assessment 
  • SCM Oracle Search setup 
  • HCM Oracle Search setup 
  • Redwood troubleshooting 
  • User acceptance testing 
  • Post-go-live support and managed services 

The objective is to ensure that Oracle Search operates as a dependable part of the Redwood experience rather than becoming a source of missing records or inconsistent user access. 

Conclusion 

Oracle Search is a foundational component of the Redwood user experience across Oracle Fusion applications. By using functional indexes, fuzzy search, relevance ranking, faceted filtering and precomputed security, Oracle Search provides a more modern alternative to traditional database-driven search. However, successful adoption depends heavily on correct setup. Profile options must be enabled in the correct sequence. Required functional indexes need to be initially ingested. ACL data must be created and maintained. Incremental security jobs should be scheduled correctly. At the same time, administrators should avoid unnecessary full ingestion jobs, repeated ACL initialization and all-user security computations during normal operations. For organizations moving deeper into Redwood, Oracle Search should therefore be treated as an ongoing platform capability requiring proper setup, security governance, monitoring and operational discipline. 

FAQs 

What is Oracle Search? 

Oracle Search is a web-style search capability within Oracle Fusion that uses optimized indexes rather than querying the entire transactional database every time a user performs a search. 

Is Oracle Search used by Redwood pages? 

Yes. Oracle identifies Oracle Search as the search mechanism used by Redwood pages across SaaS modules including HCM, SCM, CX and Finance. 

What is functional index ingestion? 

Functional index ingestion copies searchable Fusion application data into the Oracle Search index. Initial ingestion occurs during setup, while incremental ingestion keeps new and changed data current afterward. 

What is an ACL in Oracle Search? 

An Access Control List, or ACL, represents the records a user is authorized to see in Oracle Search. ACL information must be calculated and maintained so secured search results are returned correctly. 

Should functional index ingestion be scheduled regularly? 

No. Oracle advises against scheduling full functional-index ingestion because normal changes are handled through incremental ingestion and repeated initial ingestion unnecessarily consumes resources. 

Should Compute Users ACL for All Users run every day? 

No. Oracle advises against using the All Users option as a regular ACL refresh mechanism. Incremental ACL refresh jobs should handle business-as-usual security updates. 

What happens if initial ACL ingestion is run again? 

If the ACL index already exists, Oracle warns that rerunning initial ACL ingestion can wipe out the current ACL index, temporarily preventing users from receiving search results until ACL information is recomputed. 

Do Oracle Search indexes need to be manually rebuilt after every quarterly upgrade? 

No. Oracle states that automated processing handles index changes that require re-ingestion during release upgrades. If there is no structural change, administrators do not need to manually rebuild the index. 

What should be done after a P2T refresh? 

Oracle recommends treating the target environment similarly to an initial Oracle Search setup, including re-ingesting relevant indexes and recomputing appropriate ACL data. 

What is Public Worker Access? 

Public Worker Access is an Oracle Search security capability used to tailor search-result visibility for public-person searches while coexisting with existing public-person security profiles.