OAC Gen2 Governance Standard
SA & OAC Administration — Internal Reference

One Standard, Applied 64 Times

A governance and configuration reference for administering Oracle Analytics Cloud (Gen2) across a 64-application OAS → OAC migration estate — every area an admin can configure, what should be locked to a single client-wide standard, and what may legitimately vary per application.

Scope
64 OAS applications migrating to OAC Gen2
Prepared
14 July 2026
Audience
OAC / OAS platform administrators

How to read this document

Each area below states what the setting is, why a 64-instance estate should care, and — the load-bearing part — a mandatory / flexible split: what must be identical across every application to satisfy the standardization mandate, versus what can reasonably differ by app size or business need without creating drift risk.

Two evidence badges appear throughout:

Oracle-verified — confirmed this research pass against live docs.oracle.com / blogs.oracle.com pages, cross-checked by independent adversarial review, often corroborated by practitioner sources (Rittman Mead, Oracle Customer Connect).

Field guidance — established OAC/OBIEE administration practice, not re-verified against a live source this pass. Treat as a strong starting point, not a quoted Oracle standard — validate against your tenancy before writing it into a binding policy.

Violet callout boxes mark judgment calls: places where this document goes beyond what Oracle documents to recommend a specific standard. These are exactly the decisions worth taking to your governance board rather than assuming.

01

Identity & Access Management / SSO

This is the foundation everything else inherits. Get the identity domain topology and sign-on policy wrong once at the client level, and it's wrong identically in all 64 apps.

Oracle-verified

An OCI IAM identity domain is the container for users, groups, federation/provisioning, SSO configuration, and SAML/OAuth identity-provider administration — it carries the full security policy surface, including MFA, for the population it governs.

Load-bearing nuance Every identity domain ships with an active Default Sign-On Policy whose Default Sign-On Rule allows all users to sign in with just a username and password — no MFA — by default. A separate, distinct preconfigured policy, “Security Policy for OCI Console,” forces MFA for members of the Administrators group (and then all users, at lower priority) — but that policy governs sign-in to the OCI Console, not general application sign-in to OAC. Assuming “the domain has MFA” because the Console policy is active is a real, easy mistake: it does not automatically extend to OAC/application access.

Recommended standard

Mandatory, client-wide
  • One identity domain per environment tier (e.g. one for production, one shared for non-prod), federated once — never one domain per application
  • An explicit, custom Sign-On Policy that mandates MFA for OAC sign-in specifically, applied identically to every tenant — do not rely on the shipped Console-scoped MFA policy to cover this
  • One SSO/federation pattern (SAML2 or OIDC) with the corporate IdP, with identical attribute/claim mapping conventions reused for every app
  • A single password/session policy baseline (rotation, complexity, inactivity timeout) applied to the shared domain(s)
Can vary per application
  • Which application-role groups exist inside the shared domain (Area 02) — the domain topology stays fixed, the group membership doesn't
  • Session timeout duration, where a genuine business case exists (e.g. a kiosk-mode reporting app vs. an analyst workbench) — but the mechanism and where it's set should stay consistent
Field guidance

Session idle-timeout for OAC is a frequently-asked configuration on Oracle's Customer Connect community, which suggests it's routinely left at a default that doesn't match client security policy — worth an explicit, documented value rather than an inherited default. Migrations from the legacy on-prem OAS identity stack (OAM/OID) to OCI IAM are also a well-documented pain point in practitioner discussion, particularly around which accounts retain administrator standing post-cutover — plan an explicit admin-continuity check into every one of the 64 cutovers rather than assuming it carries over cleanly.

Sources Identity domains — Oracle docs Sign-on policies — Oracle docs MFA sign-on policy — Oracle docs Session timeout — Customer Connect OAM/OID → IAM pitfall — Customer Connect
02

OAC Roles & Role Hierarchy

Roles are the single highest drift-risk area in a 64-instance estate: they're trivial to improvise slightly differently in every app, and every downstream permission decision (catalog, data, semantic model) depends on them.

Oracle-verified

OAC ships seven predefined application roles — BI Service Administrator, BI Data Model Author, BI Dataload Author, DV Content Author, BI Content Author, DV Consumer, and BI Consumer — each with a documented, specific permission scope, forming an explicit inheritance hierarchy (for example, DV Content Author indirectly carries BI Content Author, DV Consumer, and BI Consumer). Since a November 2023 platform update, OAC also supports granular standalone permissions — create/edit connections, datasets, dataflows, workbooks; scheduling with Bursting or Run-As User; export to documents; connections to specific OCI AI services — that can be assigned individually to custom application roles, rather than only inherited wholesale via the seven predefined roles.

Myth, refuted this pass It is not confirmed that the predefined application roles map 1:1 to the identity domain's own default groups (ServiceAdministrator / ServiceUser / ServiceViewer), and the blanket framing “OAC is simple RBAC” did not survive adversarial review either. Don't assume a default group-to-role mapping exists out of the box — it has to be designed and documented explicitly for the client.

Recommended standard

Mandatory, client-wide
  • A single, named taxonomy of custom application roles built on top of the seven predefined roles — never inherited-only ad hoc per app
  • Every custom role maps 1:1 to a named identity-domain group; group-based assignment only, no direct-to-user role grants, anywhere
  • The November-2023 standalone-permission mechanism is the designated tool for one-off exceptions (e.g. a specific dataflow-scheduling need) — not a reason to create a new bespoke role per app
  • A single register (spreadsheet, wiki, or better — code) of every role, its OAC permission scope, and its mapped identity-domain group, kept in one place for all 64 apps, not 64 separate lists
Can vary per application
  • Which of the standard custom roles are actually populated with users in a given app — a small reporting app may only ever use two of the five defined roles
  • Standalone-permission grants for genuinely app-specific exceptions, provided they're logged against the central register
Judgment call Oracle's documentation describes the mechanics of predefined roles and standalone permissions; it does not itself prescribe “define one fixed custom-role taxonomy across all your instances.” That recommendation is this document's synthesis, made because 64 independently-invented role sets is the single most likely source of the exact drift the client wants to avoid. Confirm this approach with the governance board before treating it as policy.
Sources Predefined application roles — Oracle docs Managing permissions — Oracle Analytics blog Permissions reference — Oracle docs Understanding application roles — Oracle Analytics blog “Need a lower role than Service Admin” — Customer Connect
03

Catalog & Content Permissions

The presentation catalog is where roles become lived experience — folder structure and permission grants are what a content author actually bumps into every day.

Oracle-verified

Catalog permissions are assigned to application roles or individual users, and inheritance runs through role membership: a user inherits every permission of every role they belong to. Separately, OAC provides a “Custom” permission option that lets an admin grant a specific user authority to bypass a folder's own permission settings for a single item, without altering the folder's inherited permissions for anyone else — a targeted, auditable exception mechanism distinct from ordinary inheritance.

Recommended standard

Mandatory, client-wide
  • Group/role-based catalog grants only — the item-level “Custom” bypass is reserved for documented, sign-off-required exceptions, never a routine substitute for correct role design
  • A single top-level folder taxonomy convention (e.g. /Shared/<Domain>/<App>/Dashboards|Reports|DataSets) applied identically across all 64 apps, so any admin can navigate any app's catalog without relearning structure
  • Personal folders remain personal — never a substitute for shared, governed content, and never used to hide production reporting logic from the standard review process
Can vary per application
  • Depth of sub-folder structure below the standard top two levels, driven by an app's actual content volume
  • Which specific custom roles are granted at which folder level (Area 02 governs the roles; this area governs where they're applied)
Myth, refuted this pass Don't assume Oracle positions snapshot download/upload as “the” primary mechanism for dev → test → prod content promotion. That specific framing was checked and did not hold up — Oracle offers snapshots, Content Publisher, and Migration Manager as distinct tools, and which one is the right promotion mechanism for a 64-instance pipeline is an open question (see Research gaps), not a settled default.
Sources Assign access permissions — Oracle docs Permission inheritance — Oracle docs
04

Data Security

Row-level and object-level security is the layer most likely to be quietly re-invented per application by whichever consultant built that particular semantic model — and the hardest drift to detect after the fact, because it fails silently as “correct-looking but wrong” numbers.

Field guidance — not independently re-verified this pass

Every claim in this area comes from established OAC/OBIEE semantic-modeling practice rather than a source this research pass could confirm live. Validate specifics against current documentation before writing any of it into binding policy.

Row-level security / data filters

OAC's Semantic Modeler supports data filters defined against application roles (or, less desirably, individual users), typically driven by session variables populated at login from group membership or a mapping table — functionally the same pattern as RPD-based row-level security in OBIEE/OAS. The filter expression itself lives in the semantic model, not the catalog.

Object-level security

Presentation-layer objects (subject areas, tables, columns) can be hidden or exposed per application role at the semantic-model level, independent of catalog folder permissions — the two layers are frequently confused, and a common defect pattern is “fixing” a data-exposure problem in the catalog when the real leak is an object left visible in the semantic model.

Connection pool credentials

Connection pools can run under a single shared service account or pass through per-user database credentials. Shared-account pooling is simpler to operate and scales connection counts far better, but pushes all row-level enforcement into the semantic-model filter layer (since the database sees one identity); per-user credentials let the database itself enforce row security, at real cost to connection efficiency and administrative overhead of provisioning DB accounts per user.

Recommended standard

Mandatory, client-wide
  • One connection-pool credential strategy (shared service account or per-user passthrough) decided once at the client level — mixing the two models across 64 apps makes the eventual security review unmanageable
  • Data filters attached to application roles only, never to named individual users
  • A single naming/documentation convention for filter session variables and initialization blocks, so any semantic-model reviewer can audit any app's row-level security the same way
Can vary per application
  • The actual filter predicate logic and which dimension(s) it restricts — this is inherently business-specific
  • Whether object-level security is needed at all for a given app's subject areas
Judgment call — validate before mandating This entire area was a confirmed gap in the underlying research: no live Oracle source or forum thread on row-level security patterns, connection-pool strategy, or Essbase security specifics survived adversarial verification this pass. Treat everything above as a reasonable starting framework grounded in general OAC/OBIEE practice, not a quoted Oracle standard — a follow-up research pass specifically on data security (see Research gaps) should confirm or correct it before it goes into a binding client policy.
05

System / Instance Settings

The day-one console settings each of the 64 instances ships with its own copy of — the easiest area to let drift silently because nobody re-checks a setting that was only ever touched once, at provisioning.

Oracle-verified

Access to manage system settings — via the Console or REST API — is gated behind the BI Service Administrator role or a custom role carrying the explicit “Manage System Settings” permission. OAC exposes REST APIs to programmatically view and manage system settings (including usage-tracking options), which means every setting in this section is automatable rather than a manual, per-instance click-through.

Recommended standard

Mandatory, client-wide
  • One versioned script (using the System Settings REST API) that provisions every day-one setting identically across all 64 instances, run at provisioning and re-run to correct drift — never manual Console configuration as the source of truth
  • A single custom application role, used only by the automation service account, holding “Manage System Settings” — not ad hoc BI Service Administrator grants to individual admins for this purpose
  • Locale, timezone, currency, and date/number-format defaults fixed to one client standard (even where end users are geographically distributed — set the instance default centrally, let user-level locale preference handle the individual view)
  • Custom branding/theme elements (logo, color scheme, favicon) standardized to the client's visual identity, applied via the same automation rather than per-app manual upload
Can vary per application
  • Map/spatial layer configuration, where only a subset of apps do geospatial analysis
  • DV console defaults that are genuinely tied to a specific app's usage pattern (e.g. default landing page)
Oracle-verified

Backup and snapshot policy belongs in this area operationally (see Area 09 for the full mechanics): Oracle's own recommendation is to snapshot both at significant checkpoints and on a regular cadence, with a hard platform ceiling of 40 snapshots retained online per instance and unlimited additional snapshots exportable to offline storage.

Sources System settings & snapshot REST APIs — Oracle docs Snapshot scheduling — Oracle docs Configuring OAC — Oracle admin guide
06

Network & Connectivity

Every one of the 64 apps eventually needs to reach an on-prem or OCI-resident data source — how that path is built is either standardized once or reinvented, and mis-invented, 64 times.

Field guidance — not independently re-verified this pass

OAC connects to on-premises or non-public data sources primarily via a Private Access Channel (a managed, OCI-side network path avoiding public internet exposure) or a Remote Data Gateway agent installed near the data source. Both require explicit allow-listing of source IPs/ports and, where the source sits in a customer VCN, peering or a dynamic routing gateway configuration.

Recommended standard

Mandatory, client-wide
  • One connectivity pattern of record (Private Access Channel or Remote Data Gateway) per data-source category — e.g. “all on-prem Oracle DB sources use Gateway pattern X,” documented once, referenced by every app rather than re-decided per project
  • A single, centrally-managed allow-list / firewall-rule change process, rather than 64 independent requests to the network team with 64 different naming conventions
  • One VCN peering / routing topology reused across instances in the same region, not a bespoke network diagram per application
Can vary per application
  • Which specific data sources an app actually connects to
  • Gateway sizing/placement where genuine latency or data-residency constraints differ by app
Judgment call — validate before mandating No live Oracle source or forum discussion on Private Access Channel setup, allow-listing patterns, or Remote Data Gateway standardization survived verification this pass, despite being explicitly in scope. This section is general OAC networking knowledge, not confirmed Oracle guidance — commission a dedicated deep-dive (see Research gaps) before this becomes binding network policy, since a wrong assumption here has real security-perimeter consequences.
07

Semantic Model Governance

The RPD-equivalent layer is where OAC gives you a genuine, Oracle-native answer to “how do we version and audit 64 sets of business logic” — arguably the strongest lever available for this program.

Oracle-verified

OAC's Semantic Modeler stores each semantic model as a set of JSON files (Semantic Modeler Markup Language, SMML) that integrate natively with a Git repository — GitHub, GitLab, or Git on Oracle Visual Builder — for version control and multi-developer synchronization. Two connection methods are supported: HTTPS (via a GitHub personal access token) or SSH (via a key generated in OAC and registered with GitHub), with reusable named Git connection/user profiles for credentials, and each semantic model can point at a separate repository.

Recommended standard

Mandatory, client-wide
  • Git-backed semantic modeling required for every one of the 64 applications, without exception — Oracle provides no other native versioning or audit trail for RPD-equivalent changes
  • A single Git provider and a single authentication method (HTTPS token or SSH key), not a mix, so credential rotation and access review is one process, not 64
  • One repo-per-model convention and one branching/PR-review workflow (e.g. feature branch → PR → review → merge to main → publish) applied identically everywhere
Can vary per application
  • Model complexity, subject-area count, and modeling patterns themselves — the versioning discipline is standardized, the business content isn't
Judgment call Oracle documents the Git integration mechanics; it does not itself mandate HTTPS-vs-SSH or a specific branching strategy. Standardizing those choices is this document's recommendation, made because semantic-layer drift across 64 apps is otherwise invisible until a data discrepancy surfaces in production.
Sources Semantic Modeler ↔ GitHub integration — Oracle Analytics blog SMML reference — Oracle docs Semantic Modeler & Git — Rittman Mead The SMML language — Rittman Mead Developer-controlled BI cache settings — Oracle A-Team
08

Auditing, Monitoring & Usage Tracking

Without a standardized audit and usage-tracking baseline, a fleet of 64 instances has no consistent way to answer “who changed what, and is anyone actually using this app” — both are exactly the questions a standardization program gets asked to answer.

Field guidance — not independently re-verified this pass

OAC's Usage Tracking feature, once enabled via System Settings, logs query-level activity (user, dashboard/analysis, run time, row counts) to a dedicated usage-tracking database schema, which can itself be modeled and reported on as an administrative subject area. Administrative actions (role changes, snapshot activity, system-setting changes) are separately traceable through Console/audit views and the REST API surface confirmed in Area 05. Integrating either stream with OCI Logging/Monitoring for centralized alerting is an OCI-platform integration pattern rather than an OAC-specific feature.

Recommended standard

Mandatory, client-wide
  • Usage Tracking enabled on every one of the 64 instances, by default, at provisioning — not an opt-in left to individual app teams
  • A single usage-tracking schema/reporting model reused across apps, so fleet-wide adoption and utilization reporting is one dashboard, not 64
  • One alerting integration pattern for administrative actions (role/permission changes, system-setting changes) into whatever the client's central SIEM/monitoring stack is, applied uniformly
Can vary per application
  • Retention period for usage data, where a specific app has a distinct compliance requirement
Judgment call — validate before mandating No live source on OAC audit-log integration with OCI Logging/Monitoring, or on alerting specifics for administrative actions, survived verification this pass despite being explicitly requested. This section reflects general practice; confirm actual usage-tracking schema details and OCI integration steps against current documentation before automating against them.
09

Fleet Lifecycle Management

This is the area that only exists because there are 64 of these, not one — patching, naming, and drift detection are non-questions at single-instance scale and existential ones at fleet scale.

Oracle-verified

Backup/promotion is REST-API-automatable end to end: OAC exposes REST APIs to create, restore, register, delete, and monitor snapshots (BAR files) in OCI Object Storage, with granular, selective migration (everything, or specific content types only), a hard cap of 40 online snapshots per instance, and unlimited offline export to local filesystem or an Oracle Cloud storage bucket. This is the concrete building block a fleet-wide configuration-as-code and drift-detection program should be built on.

Recommended standard — automation baseline (Oracle-verified building blocks)

Mandatory, client-wide
  • One centrally-scripted snapshot cadence (checkpoint + regular schedule) run identically across all 64 tenants via REST API — never manual per-instance Console snapshotting
  • A uniform offline-export/retention policy, planned around the 40-online-snapshot ceiling being reached quickly across an active 64-instance estate
  • A single service-account custom role (Area 02) used to run all fleet automation, rather than per-instance ad hoc admin grants
Field guidance — not independently re-verified this pass

Beyond the confirmed snapshot/REST mechanics, a fleet of this size typically also needs: a fixed patch/update-window cadence per environment tier (Oracle applies OAC platform updates on a rolling schedule the client doesn't fully control, but the client's own maintenance-window scheduling and change-communication process around it should be identical for all 64 apps); a single instance-naming and OCI-tagging convention (environment, business domain, cost center) so the estate is queryable as one fleet rather than 64 one-offs; and a scripted drift-detection routine — periodically pulling each instance's system settings, role/permission definitions, and semantic-model Git state via REST API and diffing against the client-standard baseline defined in this document, flagging any instance that has silently diverged.

Judgment call — validate before mandating Patch cadence, naming/tagging conventions, and drift-detection tooling specifics returned no surviving verified claim this pass. The REST-API-diff approach above is a reasonable design given the confirmed API surface in Areas 05 and 09, but it is this document's proposed architecture, not an Oracle-published pattern — worth a dedicated proof-of-concept against 2–3 pilot instances before rolling out fleet-wide.
Sources Migrating OAC using snapshots — Oracle docs Snapshot REST APIs — Oracle docs Automating snapshot & data-file migration — Oracle Analytics blog
10

Capacity & Licensing Governance

At 64 instances, capacity decisions compound: a sizing mistake repeated 64 times is a budget-line problem, not a rounding error.

Oracle-verified

OAC editions carry different default OCPU service limits: Professional Edition defaults to a maximum of 4 OCPUs; Enterprise Edition defaults to 40 OCPUs under Universal Credits, but only 4 under Pay-As-You-Go or trial billing. OCI Compartment Quotas are the official mechanism for capping how many OCPUs or user seats different teams/compartments can self-provision (documented example syntax: set analytics quota ee-ocpu-count to 10 in compartment MyEnterpriseCompartment). Under Universal Credits, capacity can be flexibly scaled only within a 1–16 OCPU range; fixed tiers of 24/36/52 OCPUs exist above that but are not flexibly scalable — moving between fixed tiers, or across a defined named-user band, requires standing up a new service instance and migrating content, not an in-place resize.

Recommended standard

Mandatory, client-wide
  • One compartment-quota policy, set once via IAM policy statement, governing every app's self-provisioning ceiling — not per-app negotiation with Oracle support
  • A single, documented size-class decision tree (e.g. small / medium / large app → fixed OCPU tier or flexible 1–16 range) decided at initial provisioning for all 64 apps, so nobody discovers the fixed-tier migration cliff after the fact
  • A single edition choice (Professional vs. Enterprise) per use-case category, not decided ad hoc per project
Can vary per application
  • The actual OCPU count or user-band assigned within the agreed size classes, driven by real usage
Judgment call Because both OCPU-tier changes above 16 and user-count-band changes require a full new-instance-plus-content-migration event, get the size-class decision tree agreed before provisioning the remaining apps in the 64 — retrofitting it later means repeating exactly the migration effort this program exists to avoid.
Sources Administering OAC (Gen2) — Oracle admin guide Service quotas — Oracle docs Scaling — Oracle docs Scaling up or down — Rittman Mead

Decisions to take to the governance board

Every judgment call from the sections above, in one place — these are recommendations grounded in confirmed platform mechanics, not Oracle-prescribed defaults, and each is a real decision the client should make explicitly rather than inherit.

Consolidated from all ten governance areas
AreaDecision neededWhy it can't just default
01 · IdentityAuthor an explicit MFA-for-OAC sign-on policyShipped Console MFA policy does not cover application sign-in
02 · RolesAdopt one fixed custom-role taxonomy fleet-wideNo default group-to-role mapping exists; 64 apps will invent 64 taxonomies otherwise
03 · CatalogPick the dev→test→prod promotion tool (snapshots vs. Content Publisher vs. Migration Manager)Snapshots are not confirmed as Oracle's primary promotion mechanism — needs its own research
04 · Data securityPick one connection-pool credential model (shared vs. per-user) fleet-wideMixing models across 64 apps makes a future security review unmanageable
06 · NetworkFix one connectivity pattern (Private Access Channel vs. Remote Data Gateway) per source categoryUnverified this pass; wrong assumption has real perimeter-security consequences
07 · Semantic modelStandardize Git auth method and branching workflowOracle supports both HTTPS and SSH; not mandating one invites drift in the strongest governance lever available
09 · Fleet lifecycleApprove the REST-API drift-detection design before fleet rolloutProposed architecture, not an Oracle-published pattern — pilot first
10 · CapacityAgree the app size-class → OCPU-tier decision tree before provisioning the rest of the 64Fixed-tier and user-band changes require a full migration event, not a resize

Research gaps — recommended follow-up

These returned no independently-verified claim in this research pass despite being explicitly in scope. The field guidance sections above are a reasonable working start, not a substitute for confirming them directly.

  • Oracle's (and practitioner) actual recommended pattern for row-level security / data-filter implementation, and for connection-pool credential strategy (shared service account vs. per-user)
  • Documented patterns for OAC network connectivity at multi-tenant scale — Private Access Channel setup, on-prem allow-listing, Remote Data Gateway standardization — and how to avoid per-instance network drift
  • Oracle's actual official position on the preferred content-promotion tool for dev/test/prod lifecycles — snapshots vs. Content Publisher vs. Migration Manager vs. the Baseline Validation Tool
  • Oracle-published or practitioner guidance specifically on configuration-drift detection across 50+ OAC instances, beyond the individual REST API building blocks confirmed here

Primary sources

Every Oracle-verified claim in this document traces to a live-fetched page as of 14 July 2026, cross-checked by independent adversarial review. OAC's permissions model changed materially as recently as November 2023 — re-validate this document against Oracle's release notes periodically rather than treating it as permanently current.