Skip to content
PlaidCloud

HFM/FCCS: Read Data (Ad-hoc)

Description

Section titled “Description”

Reads an ad-hoc data slice from Oracle FCCS (Financial Consolidation and Close, EPM Cloud) over your HFM/FCCS connection, by point of view (POV) rather than by writing a query. A finance user picks an application, builds a POV from the FCCS dimensions, and runs the step; the returned grid lands automatically as a project table (schema-on-read — the table is created from the grid’s columns). It feels like a live query, but under the hood the step submits an export job to FCCS, polls it to completion, then fetches and lands the result — so a long-running slice doesn’t block, and it needs no ticket to the HFM team.

This step appears in the step menu under Oracle EPM (HFM/FCCS).

Configuration

Section titled “Configuration”

Source and Target

Section titled “Source and Target”
Field Required Notes
HFM/FCCS Connection Yes The HFM/FCCS connection to read through.
Environment Yes The connection’s environment.
Application Yes The FCCS application to read from. Defaults to the connection’s Default Application if one is set. Picking the application drives live member discovery for the POV.
Target Table Yes The project table the returned grid lands in.

Point of View

Section titled “Point of View”

Build the slice from the FCCS dimensions. On supported pods the member lists auto-populate from live metadata discovery once a connection and application are chosen; on older pods you type member names manually.

Dimension Required Notes
Scenario Yes
Year Yes
Period Yes
Entity Bounded Must name a bounded slice — the form rejects an empty selection, “all”, or a selection wider than 500 members. Keep it scoped so the export doesn’t lock the application.
Account No
Custom1–Custom4 No The application’s custom dimensions.
ICP No Intercompany.
View No
Value No

An unset optional dimension applies no filter on that axis (FCCS’s default member is used).

Bound Target

Section titled “Bound Target”

Off by default — each run lands an ad-hoc slice that overwrites the target table.

Field Notes
Bound target (scheduled recurring load) When checked, the target becomes a persistent table: the step merges into it with a keyset upsert instead of overwriting, and the schema grows additively when a later grid brings new columns (a new column raises a warning, never a failure). Placing the step in a scheduled workflow then gives a recurring load that accumulates rather than wipes.
Key Columns Enabled only with Bound target on. Comma-separated columns that form the merge key (for example Entity, Account). Leave it empty to use the POV dimension columns present in the landed grid as the merge key.

How It Works

Section titled “How It Works”
Submit job Poll Fetch grid Land table while running… Repeat POVserved from cache
A run submits an export job, polls it, fetches the grid, and lands a table. The same point of view requested again is served from the already-landed copy.

While the job runs, the step shows a polling status. When it lands, the table is created from the grid’s columns — no schema to define up front.

Caching

Section titled “Caching”

The same POV requested again is served from the already-landed table, instantly, instead of re-submitting the export to FCCS. A run is keyed by application, target table, point of view, and an as-of tag (default latest); a repeat that resolves to an already-landed slice reports that the table was left in place rather than re-writing it. Change the as-of tag when you want to force a fresh extract of the same POV.

Row-Level Security

Section titled “Row-Level Security”

The landed grid’s entity axis is normalized to a column named exactly Entity, so the table is row-level-security-ready — an administrator can govern it with Row Access so self-serve users only see the entities they’re entitled to.

This is governed under admin control, not automatic. Because the extract runs under the connection’s service account, PlaidCloud will not let the step declare its own security. An administrator follows the standard Row Access workflow:

  1. Publish the landed table for reporting.
  2. Declare the Entity column as a governing attribute (default deny).
  3. Approve the first governed write.
  4. Reconcile so grants take effect.

Until an administrator does this, the table is not filtered. See Managing Security Groups and Assignments.

Capability Limits

Section titled “Capability Limits”
Limitation What it means
Read-only Extracts a slice from FCCS. It does not write consolidation data, run consolidations, or post back.
Bounded entity required The form rejects an empty, “all”, or wider-than-500-member entity selection, and a single aggregate member can still expand server side — keep the slice scoped.
Manual members on older pods Where a pod doesn’t expose the metadata endpoint, member lists don’t auto-populate; enter member names by hand.
Row-level security is admin-governed The Entity column is RLS-ready, but an administrator must publish, declare, approve the first write, and reconcile before the table is filtered.
Section titled “Related”