Search Results cs_sr_tsk_tmpl_seq_rules




Overview
Explore in AI Chat

Overview

CS_SR_TSK_TMPL_SEQ_RULES is a Service (CS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that defines the sequence in which template groups are searched when the Service Request task template engine resolves the appropriate template for a given service request context. Rather than treating template resolution as a single static lookup, Oracle Service allows multiple template groups to be evaluated in a defined priority order; this table stores the search rules that govern that ordering. Each row represents one search rule, identified by a surrogate SEARCH_RULE_ID, and carries a numeric SEARCH_SEQUENCE that determines evaluation priority plus an ACTIVE_FLAG that allows a rule to be enabled or disabled without deletion.

From a Data Vault modeling perspective, the ETRM metadata classifies this object heuristically as standalone — that is, it behaves as a reference or lookup construct without a natural parent hub/link relationship in the mined FK structure. It is best treated as a small reference/dimension-style table keyed on its own surrogate identifier rather than as a transactional fact or junction.

Key Information Stored

The table is documented with 12 physical columns. The most significant are listed below.

  • SEARCH_RULE_ID — The surrogate primary key, enforced by CS_SR_TSK_TMPL_SEQ_RULES_PK. It uniquely identifies each search rule row.
  • SEARCH_RULE_CODE — A user-meaningful business identifier for the search rule, used for readability in setup and reporting.
  • SEARCH_SEQUENCE — The numeric ordering value that determines the order in which template groups are evaluated. Lower values are typically evaluated first.
  • ACTIVE_FLAG — Controls whether the rule participates in the search sequence. Inactive rules are retained for history but skipped at runtime.
  • SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enabling multi-org/security-group partitioning of the rule definition.
  • OBJECT_VERSION_NUMBER — Optimistic locking column used by the OAF/BC4J framework to detect concurrent updates.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS WHO columns for audit and row-level change tracking.
  • ZD_EDITION_NAME — Edition-based redefinition (EBR) column supporting online patching in 12.2.2.

Two columns form the documented unique index CS_SR_TSK_TMPL_SEQ_RULES_U1: SEARCH_RULE_ID and ZD_EDITION_NAME. Because the surrogate key alone already implies uniqueness, this index primarily guarantees one row per rule per edition, which is essential for EBR compatibility. SEARCH_RULE_CODE is the natural business-key candidate when querying by name rather than by ID.

Common Use Cases and Queries

Typical scenarios include troubleshooting why an unexpected template is applied, auditing which rules are active, and reporting on sequence ordering. A representative query retrieves active rules in evaluation order:

  • SELECT search_rule_id, search_rule_code, search_sequence FROM cs_sr_tsk_tmpl_seq_rules WHERE active_flag = 'Y' ORDER BY search_sequence;
  • Security-group scoping: filter by SECURITY_GROUP_ID to restrict results to the operating unit or security context in use.
  • Audit reporting: join the WHO columns to FND_USER to identify who last changed a rule and when.
  • Edition-aware queries in 12.2.2 should reference ZD_EDITION_NAME to avoid picking up shadow rows during patching.

Because the table is small, it is commonly extracted into BI Publisher or OBIEE reports as a setup/reference dataset rather than as a high-volume fact source.

Related Objects

Relationship data identifies one documented foreign key and the primary-key structure. The most significant related objects are:

  • FND_SECURITY_GROUPS — joined on CS_SR_TSK_TMPL_SEQ_RULES.SECURITY_GROUP_ID. Confirms the security partition for each rule.
  • CS_SR_TSK_TMPL_SEQ_RULES_PK — the primary key constraint on SEARCH_RULE_ID.
  • CS_SR_TSK_TMPL_SEQ_RULES_U1 — the unique index on (SEARCH_RULE_ID, ZD_EDITION_NAME) supporting EBR.
  • Template-group and task-template setup tables in the CS schema, which reference search rules to resolve template selection at runtime.
  • Service Request processing APIs and the template resolution engine, which read ACTIVE_FLAG and SEARCH_SEQUENCE directly.

The table is standalone in FK terms, so joins to dependent template objects are typically driven by application logic rather than database-enforced constraints.