Results for “team_desc”

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

Overview

JTF_RS_TEAMS_TL is the translation (language) table for JTF_RS_TEAMS_B, the base table that stores resource team definitions in the Oracle CRM Foundation (JTF) product family. In Oracle EBS 12.1.1 and 12.2.2, the _TL suffix denotes a Multi-Language Support (MLS) table. It exists solely to hold the translatable text columns of a team record — specifically the team name and description — duplicated across every installed language, while non-translatable attributes (ownership, audit, security, and identifiers) remain in the base table. Records are joined back to JTF_RS_TEAMS_B through the TEAM_ID column, and the active language is driven by the session LANGUAGE column.

From a Data Vault modeling perspective, the mined FK structure classifies this object as satellite-leaning. The natural hub is JTF_RS_TEAMS_B (identified by TEAM_ID), and JTF_RS_TEAMS_TL behaves as a descriptive satellite whose grain is partitioned by LANGUAGE. In practice this means one logical team produces multiple translated rows — one per language — all sharing the same TEAM_ID.

Key Information Stored

The table encompasses 11 documented columns. The most significant are the language discriminator and the descriptive text fields:

• TEAM_ID — Surrogate/foreign key identifying the owning team record in JTF_RS_TEAMS_B; part of the composite primary key.
• LANGUAGE — The language code in which the translated text is stored; the other half of the composite primary key JTF_RS_TEAMS_TL_PK.
• TEAM_NAME — The translated, user-facing name of the resource team.
• TEAM_DESC — The translated descriptive text for the team.
• SOURCE_LANG — Identifies the source/originating language of the text, used during MLS resolution and translation workflows.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enabling Multi-Org / security-group access control on translated rows.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who audit columns tracking row provenance and change history.

The composite primary key is JTF_RS_TEAMS_TL_PK (LANGUAGE, TEAM_ID). The unique index JTF_RS_TEAMS_TL_U1 (TEAM_ID, LANGUAGE) represents the documented business-key candidate, guaranteeing one translation row per team per language.

Common Use Cases and Queries

The dominant use case is joining translated text to the base team record for a specific language in reports, concurrent programs, and form-based LOVs. A typical query pattern restricts on the current session language:

• Retrieve team names in a chosen language: SELECT b.TEAM_ID, t.TEAM_NAME FROM JTF_RS_TEAMS_B b, JTF_RS_TEAMS_TL t WHERE b.TEAM_ID = t.TEAM_ID AND t.LANGUAGE = USERENV('LANG');
• List all translations for a given team: SELECT LANGUAGE, TEAM_NAME, TEAM_DESC FROM JTF_RS_TEAMS_TL WHERE TEAM_ID = :team_id;
• Missing-translation audit: query the base table with an anti-join against JTF_RS_TEAMS_TL to find teams lacking a row for a required language.

Because SECURITY_GROUP_ID is present, multilingual reports frequently append a security-group predicate to honor Multi-Org access. Resource Manager and CRM team-assignment functionality resolves display names through this table rather than the base table.

Related Objects

• JTF_RS_TEAMS_B — The base table; the primary/detail relationship on TEAM_ID is the core of any query.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID to enforce security-group partitioning.
• JTF_RS_TEAM_MEMBERS — Stores team membership and depends on team identity established via TEAM_ID.
• JTF_RS_GROUPS_B / JTF_RS_GROUPS_TL — Parallel MLS-enabled resource objects that share the same _B/_TL design and are commonly queried alongside teams.
• JTF_RS_TEAMS_VL (or equivalent MLS view) — The translated view that applications query instead of touching the tables directly, automating the language join.
• FND_LANGUAGES — Supplies the installed language list that maps to the LANGUAGE column values.

Direct DML against this table should be avoided; instead, use Oracle's MLS APIs and the translated views so that LANGUAGE, SOURCE_LANG, and audit columns remain consistent with the base record.