Search Security Recommendations

Search results displayed from PeopleSoft Search Framework for Global Search are based on the user’s security access (permission list) to the underlying component shown in the search results. Therefore, if a user does not have access to a particular component, then the user will not see search results. In addition, row level security is applied to keyword search results for Search Pages based on the row level access for the user. This is especially true for SetID and business unit security. If business unit security is enabled, the only valid search results for the enabled business unit is displayed to the user. If Business Unit/SetID types of security are being used, then they must be set up before building search indexes so that all results contain the required security attributes needed.

There are several way to generally set up security, including setting up security by and individual user ID. It is not recommended that setting up security by user ID be used with PeopleSoft Search due to the maintenance involved with search indexes. Indexes that are secured by user will have to be rebuilt every time a user is added or removed. This can cause significant time delays when indexes are large. Therefore, it is recommended that security by permission list be used when Business Unit/SetID security is enabled.

Depending on your FSCM application, there may also be other row level security applied which would prevent the user having access to specific search results. This security has been provided by the application depending on the need for granular restrictions. An example of such security would be access to  a supplier contract or expense report by user.  These indexes may be more complex to manage since specific users may need to be maintained within each and every individual search result.   In some cases, such as Supplier Contracts Management, search results may be updated via incremental index updates when a user changes on a specific searchable object and the update happens automatically.    In other cases, changes to granular search security will require a rebuild of your index(es) for the new security to take effect.  Review your application-specific documentation for information on row level security which may be enabled for that application. Depending on the type of security implemented, these indexes may require more frequent index rebuilds if these parameters change often within your organization.

Note:

It is recommended that security by permission list is used when Business Unit/SetID are enabled to avoid frequent index rebuilds every time there are changes within your organization.