Search Results wf_ntf_security_policies




Overview
Explore in AI Chat

Overview

WF_NTF_SECURITY_POLICIES is a configuration table owned by the APPLSYS schema within the FND – Application Object Library product of Oracle E-Business Suite. Its documented purpose is to store security policies that govern notification behavior in the Oracle Workflow notification subsystem. The table defines named policies that control whether outbound electronic mail is permitted, providing administrators with a mechanism to suppress or allow e-mail delivery at a policy level rather than per individual notification or recipient.

In Oracle EBS 12.1.1 and 12.2.2 the physical structure of this object is identical and deliberately minimal. The ETRM documentation records only two columns, POLICY_NAME and EMAIL_ALLOWED, under the primary key constraint WF_NTF_SECURITY_POLICIES_PK, which is defined on POLICY_NAME. Because the primary key is a natural business key rather than a generated surrogate, the table behaves as a small, slowly changing reference list. The provided metadata classifies the object heuristically as standalone under the Data Vault model, meaning no foreign key dependencies to or from other tables were mined. As a modeling suggestion only, this object is best treated as a reference or lookup entity rather than a hub, link, or satellite, since it holds descriptive policy definitions instead of relationship or transactional history.

Key Information Stored

The documented column set is compact, and both columns carry functional weight:

  • POLICY_NAME — The primary key column and the business identifier for each security policy. It holds the unique name by which a policy is referenced when assigned to a workflow notification or mailer configuration. Because WF_NTF_SECURITY_POLICIES_PK is defined on this single column, POLICY_NAME is simultaneously the surrogate identifier and the sole business-key candidate; no separate unique index is documented.
  • EMAIL_ALLOWED — The flag controlling whether e-mail delivery is permitted for notifications governed by the named policy. This is the operational payload of the table and the value most administrators configure.

No additional columns are documented in the 12.2.2 physical schema. Any further attributes observed in a specific environment should be validated against the actual data dictionary, since the ETRM extract records a total column count of two.

Common Use Cases and Queries

Typical scenarios include auditing which policies permit e-mail, verifying the flag value during notification troubleshooting, and confirming that a policy name expected by a workflow definition actually exists. Because the table is small, queries are simple and inexpensive.

To list all policies and their mail permission status:

SELECT policy_name, email_allowed
FROM   applsys.wf_ntf_security_policies
ORDER  BY policy_name;

To identify policies that suppress e-mail delivery:

SELECT policy_name
FROM   applsys.wf_ntf_security_policies
WHERE  email_allowed = 'N';

To confirm that a specific policy exists before associating it with a notification:

SELECT COUNT(*)
FROM   applsys.wf_ntf_security_policies
WHERE  policy_name = :p_policy_name;

Reporting use is generally limited to administration audits and validation of mailer configuration, since the table contains no transactional or historical data.

Related Objects

The mined relationship data identifies WF_NTF_SECURITY_POLICIES as standalone, with no enforced foreign key relationships to or from other tables. Consequently, no join columns to related objects are documented, and dependencies are functional rather than referential. The most significant associated objects are those in the Oracle Workflow notification and mailer infrastructure that consume the POLICY_NAME value at runtime, including the notification mailer configuration and the workflow notification preference and attribute tables in the APPLSYS and WF schemas. Administrators should treat any linkage between this table and downstream notification objects as logical, driven by matching policy names rather than by database constraints. Because the policy name is the only identifying value, modifications such as renaming a policy can break implicit references, and changes should be coordinated with the notification components that depend on it.