Results for “minimum_responses_required”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IES_SVY_CYCLES_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, defined within the IES – Scripting product family. In the Oracle EBS release context of 12.1.1 and 12.2.2, this object exposes the survey cycle definition data managed by the Scripting component. A survey cycle represents a discrete instance or round of a survey, allowing a single survey definition to be run multiple times with independent scheduling, status, and response collection parameters. The view presents survey cycle records in a denormalized, read-friendly form, making it suitable for concurrent program extracts, Oracle Reports, BI Publisher data templates, OAF-based inquiry pages, and integration interfaces that must retrieve cycle metadata without joining the underlying transactional tables directly.

The object carries a status of VALID, and its documented metadata confirms it is a simple projection view rather than a complex join. This design choice means consumers receive one row for each survey cycle row visible under the current operating unit context, filtered by the multilingual and security columns present in the base table.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, IES_SVY_CYCLES_V is defined exclusively over a single referenced base object: the synonym IES_SVY_CYCLES_ALL, which resolves to the underlying survey cycle table in the APPS schema. The view text performs a straightforward SELECT of all substantive columns from that synonym with no WHERE clause, no DISTINCT, and no aggregation, so the view is a one-to-one passthrough of the base table's rows.

Because the underlying object is an _ALL table, it is expected to carry the standard multi-org columns ORG_ID and SECURITY_GROUP_ID, together with the standard WHO audit columns. The view therefore preserves organization partitioning and security group semantics for downstream consumers, and any application logic that depends on operating unit or security group filtering remains applicable when querying through the view.

Key Columns

• SURVEY_CYCLE_ID – Primary identifier for the survey cycle record; used as the foreign key in response and invitation tables.
• OBJECT_VERSION_NUMBER – Optimistic locking column used by the framework to detect concurrent updates.
• ORG_ID – Operating unit identifier supporting multi-org data segregation.
• SURVEY_ID – Reference to the parent survey definition to which this cycle belongs.
• SURVEY_CYCLE_NAME – User-facing label for the cycle, typically shown in list pages and reports.
• MINIMUM_RESPONSES_REQUIRED – Threshold of responses that must be collected before the cycle is considered complete.
• ANONYMOUS_CODE – Indicator controlling whether responses are captured anonymously.
• CAMPAIGN_ID – Link to the associated campaign used to distribute the survey.
• CYCLE_STATUS_CODE – Lifecycle status of the cycle (for example, draft, active, or closed).
• F_DELETEDFLAG – Soft-delete flag; rows marked deleted should generally be excluded from active reporting.
• SECURITY_GROUP_ID – Security grouping identifier applied by the Scripting framework.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard WHO audit columns.

Common Use Cases and Queries

Typical scenarios include listing active cycles for a survey, reporting response thresholds, and exposing cycle metadata to integrations that create invitations or collect responses. A representative query filtering active, non-deleted cycles for one operating unit is:

• SELECT SURVEY_CYCLE_ID, SURVEY_ID, SURVEY_CYCLE_NAME, CYCLE_STATUS_CODE, MINIMUM_RESPONSES_REQUIRED, CAMPAIGN_ID FROM APPS.IES_SVY_CYCLES_V WHERE ORG_ID = :p_org_id AND NVL(F_DELETEDFLAG,'N') = 'N' AND CYCLE_STATUS_CODE = 'ACTIVE' ORDER BY SURVEY_CYCLE_NAME;

A second common pattern resolves cycle details for a known survey and joins to response data by SURVEY_CYCLE_ID for utilization metrics. Because the view applies no filtering itself, report authors should always constrain on ORG_ID, F_DELETEDFLAG, and where applicable SECURITY_GROUP_ID to avoid returning rows outside the intended business context.