Return to Navigation

Understanding the Configurable Search

You can use the search configuration component to control the appearance and behavior of the search pages used in PeopleSoft CRM applications. Additionally, you can give your users the ability to personalize the appearance and behavior of specific search pages.

Because some PeopleSoft CRM applications have added application-specific logic to the configuration settings as well as elements and processing rules to specific areas of the search pages, you may not be able to control all aspects of a search page through the search configuration component.

This section discusses:

PeopleSoft delivers configurable search pages for all major transaction components.

Note: Business unit security does not work when the in operator is used. PeopleSoft CRM also does not support searching across setIDs and business units as these are very special fields. The business unit that you select on the search page drives most of the other values that you can view. For example, you can view certain values for case status based on the business unit that you select. If you use the in operator to select multiple business units, it only shows the case statuses for one of the business units. Generally speaking, you can't search for transactions across business units because the core architecture inherent in PeopleTools that is associated with business units and setIDs is not supported and is too complex to properly handle these situations.

Using the pages that make up the search configuration component, you can control:

  • User personalization options.

  • Results grid initialization.

    When the user first accesses the page, these options determine whether the system will populate the grid with the user's most recently used search criteria, use the user's saved search information that is designated as their default, or not populate the grid at all.

  • Search button position (top, bottom, or both).

  • Search section collapse.

    This option determines whether the search area is collapsed or expanded when a user first accesses the page. You can also control whether the search area collapses automatically after the user performs a search.

  • Advanced and basic lookup defaults.

    This option determines whether basic search, advanced search, or both are available to the user. If you make both available, you must designate one as the default.

  • Dataset rules.

    You can use dataset rules to limit the data that a particular user can see. The dataset rules must be created before adding the dataset name to the Advanced Options page. Clicking the Edit Dataset Definition link takes you to the dataset setup pages.

  • Application security.

    Use this option to enable application security and secure access of data and functions within transactions.

    See Understanding PeopleSoft CRM Security.

  • Informational line for the results grid.

  • Component transfers (when only one search result is found).

  • Maximum rows to show in the results grid.

  • Update options.

    Use this option to give users the ability to edit data in the results grid.

  • Search PeopleCode.

    This option gives developers the ability to secure result data by running a function or application class method against the rows of data returned in a search.

    Developers who are using extended classes can override the search code with Application Class IDs. The system executes this code last, before the search list is created.

  • Message displays and system behavior when the user does not enter any search criteria.

  • Field relationships.

    When a lookup field has a relationship with another field on the page (for example, Country and State), there should be a work record that includes the high order search field of the other field. In this example that would be Country.

  • SQL search statements.

    This option is used to turn on technical programming details (SQL statements) that are displayed at the bottom of the page. Use this option in your development environment only for tuning purposes; it should not be exposed in a production environment.

Using the pages that make up the search configuration component, you can control:

  • Search fields (which ones to display on the search page).

  • Field order.

  • Field labels.

  • Edit types (drop-down list box, translate table, yes/no, and so on).

  • Edit table.

  • Search field use (required, display only, hidden, show transfer button).

  • Display options.

    This option controls whether the field is shown in the results grid.

  • Prompt control fields.

    Use this option to specify the appropriate prompt field for business unit and setID search fields.

  • Optional field-specific help messages.

    If implemented, the system displays an icon next to the field associated with the message.

  • Operators.

    You can select the operators (begins with, in, and so on) that you want to make available for the field and then select the operator that you want to use as the default.

    Warning! Using the contains operator on a large database could degrade system performance. Therefore, PeopleSoft has decided not to deliver its applications with contains as a search operator. You can choose to enable this operator to broaden your search capability but you may want to test system performance before you release it to your user base.

Based on how you set up the search page, users can personalize options on the search page. These options include:

  • Search button position.

  • Search defaults (either basic or advanced).

  • Search section collapse.

    This option determines whether the search area is collapsed or expanded when a user first accesses the page. This option also determines whether the search area is collapsed or expanded after searching.

  • Results grid initialization.

    When the user first accesses the page, these options determine whether the system will populate the grid with the user's most recently used search criteria, use the user's saved search information that is designated as their default, or not populate the grid at all.

  • Search field selection.

    The user can decide which fields to display or hide on the search page.

The search configuration component enables you to hide some columns in the search results grid when the page initially appears and give users the ability to hide or show search result grid columns from their personalized search if they want.

When a user executes a search on a configurable search page using a field that searches the business object directory, the system produces the following results, depending on the operator that was used:

Operator

Result

equals (=)

This search operator uses the underlying business object ID and role type associated with the field on the Configurable Search - Setup page to perform the lookup.

If the search field supports multiple roles and there are records in the table that have the same business object ID with different role types on different records, the system only matches the combination that you selected when you performed the search. It will not search only by the business object ID.

begins with and contains

These searches use the actual value entered by the user in the search field to perform the search with a like operator (“value%” or “%value%” respectively).

While these operators enable you to search by name, you may also get names that match the pattern of the name specified. Use these operator if you want to do cross-role searching for a single business object ID.

For example, if you execute a search on the Sender field on the Search Inbound Email page using the begins with operator, the system uses a like operator to find the person's name. The system ignores the BO_ID_CONTACT and ROLE_TYPE_ID_CNTCT values.

If you execute a search using the equals (=) operator, the system looks for an exact match of the BO_ID_CONTACT and ROLE_TYPE_ID fields. This means that if you want to search for a person without regard to the role with which they are associated, you must use the begins with operator, because the equals (=) operator matches the role as well as the contact.

In addition to letting users save searches that they commonly perform, the search configuration component also enables the saving of a number of recently used search criteria that users can use in future transaction lookup.

When a user performs a search at runtime, the system automatically saves the search criteria and make this search available like a saved search that the user creates manually. Users in the system has their own lists of saved searches and recent searches.

To set up this feature, implementers configure the maximum number of recent searches allowed and the naming convention. The recommended number for displaying recent searches at runtime is 10. A system message appears if you enter a greater number. If this value is reset at a later time and it is smaller than the number of actual recent searches that any user has, the system automatically removes the extra searches of that user (the oldest goes first).

Note: If a user selects a recent search that has been removed from the database (possible if the user has multiple browsers open for the same transaction search page, and the search list is updated in one browser but not the rest), a system message appears and suggests that the user to refresh the browser to get the latest search list.

Implementers configure how recent searches are named. Two modes are available: simple and verbose. Using the simple mode, each recent search is named with its search values; using the verbose mode, each of them is named with search field and value pairs.

The system lists recent searches chronologically (followed by saved searches) and they are assigned with order number. For example, the newest search is prefixed with 1, the second newest search 2, and so on. Saved searches are ordered alphabetically. If a user performs a saved search at runtime, the saved search is also listed as the newest recent search at the top, prefixed with 1.

This feature is disabled by default.