OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

Soft limits keep you out of trouble, hard limits keep moving, and there is one checkbox worth verifying today.

In the same session with Oracle's OCI identity team that I wrote about in my last post, one of our architects asked a question I suspect a lot of enterprise customers carry around quietly. Setting aside divestitures and business unit boundaries, are there scale limits that should push us toward multiple tenancies?

It is a fair question. Policy limits in particular had shaped some of our earlier decisions. The answer, and the conversation it opened up, covered service limits, policy design, and identity disaster recovery. All three are worth writing down.

Soft limits and hard limits are different things

Oracle drew a clean distinction between the two.

Soft limits are bumpers. They exist to keep you from getting yourself into trouble. A default cap on how many VMs you can launch is not there because Oracle cannot run more. It is there because a sudden jump to a very large number usually means something went wrong, a runaway script or a mistake, and the next call is usually a refund request. Need more? Ask, and the limit goes up.

Hard limits are architectural. They exist because going past them could affect you or other tenants. The example given was vaults backed by dedicated hardware security module capacity. A region has a finite pool, and some code paths were written with an expected upper bound. Asking for a handful more is routine. Asking for an unusually large number in one tenancy becomes a real conversation.

Two things stood out to me. Oracle tracks hard limits proactively and works with customers before they reach them. And hard limits are not static. Oracle continually evaluates them and raises them as customers demonstrate a need.

For perspective, Oracle noted that some customers run thousands of VMs across dozens of regions and move enormous volumes of data continuously. A typical enterprise application footprint, ours included, is nowhere near the hard limits they see elsewhere.

The policy limit story is a good example

IAM policy limits used to be one of those hard limits, and the old tenancy-wide ceiling was tight for large organizations. Customers told Oracle they needed more. Oracle worked with them, changed how the policy engine evaluates policies, and the old ceiling no longer applies the way it once did. The limit is now applied along the compartment hierarchy rather than as a single flat number for the tenancy.

The practical consequence is that placement matters. Put everything at the root and you concentrate your budget in one place. Put policies in the compartments where they are actually needed and the limit largely stops being a constraint. Check the current OCI documentation for exact numbers, because they have moved and will move again.

Oracle also shared, with the appropriate grain of salt for anything roadmap-related, that a significant effort is underway to raise policy limits from the hundreds into the thousands. Their suggestion was to understand where you are and where Oracle is heading before investing heavily in reducing policy counts on a short timeline.

The default policies are simple on purpose

If you have several Fusion pods, you have probably noticed that each identity domain arrives with its own set of policies at the root of the tenancy. Multiply that across many domains and the root gets crowded quickly.

Oracle was direct about why those policies look the way they do. They are intentionally simple, typically one group, one resource type, one location per statement. That makes them easy to read and reason about, and they were designed with typical customers in mind rather than those running a large number of identity domains.

Two things follow from that:

·        They can be consolidated. Multiple groups and resource types can be combined into fewer statements while still expressing least privilege. Our team has worked through this. It is very doable, though it takes care.

·        Most of them do not have to live at the root. A small number of tenancy-level permissions do, but most resources, and the policies governing them, can live in compartments.

Oracle offered two perspectives that I think are both right. First, simple policies have value. If they work for you, do not rush to optimize them away just to reduce a count, especially with limits increasing. Second, from a security standpoint, a crowded root is not ideal. The more that lives at the root, the more there is to watch. Our own cleanup effort is aimed at the second point without giving up the readability of the first.

Oracle also offered to walk through the consolidation with us, which I appreciated.

Identity domain disaster recovery: go check the box

This is the part of the session I would most encourage other customers to act on.

A tenancy's Default identity domain is homed in the tenancy's home region. If disaster recovery is enabled, and a region-level disaster takes the home region down, Oracle is responsible for bringing that domain up in the paired disaster recovery region so you can keep managing your resources elsewhere.

The details matter:

·        The domain comes back with the same URL and hostname.

·        The IP address may change.

·        Client IDs, secrets, and the applications relying on the domain continue to work.

·        It does not cost anything extra.

·        It only happens if the option is enabled. If it is not, Oracle cannot move the domain.

That last point is why I say go check. It takes minutes to confirm, and you do not want to find out during an incident.

HA and DR are not the same thing

Oracle made a distinction that is easy to blur. Within a region, identity domains run as highly available microservices. Disaster recovery to another region is something different, reserved for serious, region-level events expected to last hours or days.

A 20 or 30 minute disruption will usually not trigger a regional failover, because relocating a domain takes time and would likely take longer than the disruption itself. That is a sensible trade-off, and it should shape your expectations and your runbooks. Identity DR protects you from catastrophe, not from every hiccup.

Make sure identity lives where your workloads live

One more design point came out of this. Identity domains serve the workloads that depend on them. If a domain is homed in a different region from the applications it supports, which happened with some older IDCS provisioning, an outage in the identity region can affect production running in a perfectly healthy region. Oracle acknowledged the pattern and agreed it is something to solve for as part of a longer-term identity plan.

My own addition, not something Oracle said: if you have firewall rules or allowlists tied to IP addresses for identity endpoints, revisit them. Oracle's DR commitment is built around the hostname. Build around the hostname too.

A short checklist

1.      Confirm disaster recovery is enabled for the identity domains you depend on.

2.      Confirm each domain's home region aligns with the region where the workloads it serves run.

3.      Replace IP-based dependencies on identity endpoints with hostname-based ones.

4.      Inventory the policies at your root. Separate the few that truly must be there from those that can move to compartments.

5.      Consolidate where it improves clarity, not only to reduce a count, and watch Oracle's limit increases before committing to a large reduction effort.

6.      If you think you are approaching a hard limit, talk to Oracle early. They would rather hear from you before you hit it.

They do not stand still

Near the end of the session, someone on our side observed that there always seems to be something new coming in OCI. Oracle's reply was simple: they don't stand still.

That feels like the right note to end on. Several constraints that shaped enterprise OCI designs a few years ago have already been lifted, and more are on the way. Design for today's limits, but revisit the assumptions behind your architecture regularly. Some of the reasons you split things apart may not apply anymore.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.

One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

 One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

A tenancy is a hard boundary by design. Once that clicks, most of the other decisions get easier.

If your organization has been on Oracle Cloud for a while, there is a good chance your footprint did not arrive all at once. Fusion pods came first, or PaaS services did. A new module showed up with its own activation email. Somebody made a reasonable call at the time, and a few years later you are looking at several tenancies, a growing list of identity domains, and a question nobody can answer in one sentence: where should the next thing go?

That is where our team is. We recently sat down with Oracle's OCI identity team to talk less about how we got here and more about where Oracle is heading, and how a customer should think about tenancies and identity going forward. I want to write down what I took away from it.

Start with the vocabulary

Oracle Cloud identity runs on OCI IAM with identity domains. If you have been around long enough to remember IDCS, identity domains are where that capability lives now.

When you get a tenancy, you get one identity domain automatically, the Default domain. It exists so you can sign in to the tenancy, manage it, and do everything else an administrator does there. You can create additional domains for other purposes.

When you buy Fusion, things get more interesting.

Why every Fusion pod has its own identity domain

Buy three Fusion pods for development, test, and production, and you get three identity domains, one pre-wired to each pod, in addition to the tenancy's Default domain.

That surprises people at first. It seems like a lot of identity. The reasoning is sound, and the example Oracle used made it click for me.

Picture a developer configuring a timesheet approval flow. To prove it works, they need to sign in as the employee who submits the timesheet, then the manager who approves it, then the director above that. In a development environment that usually means a set of test users the developer controls. You cannot wire that environment to your production corporate identity provider, because those test personas do not, and should not, exist there.

So each pod is its own island of identity. Development gets test identities. Pre-production connects to your pre-production identity system. Production connects to production. Not every customer works that way, but it is a very common pattern and Oracle has to support the customers who do.

The greenfield picture

This is the part I found most clarifying. If you provision PaaS services to support a Fusion environment, such as Visual Builder, Integration, Analytics Cloud, Fusion Data Intelligence (formerly Fusion Analytics Warehouse), or Autonomous Database, you provision them in the same tenancy using the same identity domain as the pod they support.

Do that, and they are pre-integrated. No extra trust to set up, and no federation to maintain between services that are supposed to behave as one environment.

The picture Oracle described for a customer starting today looks like this:

·        One tenancy, with compartments per environment.

·        A development compartment holding the dev Fusion pod and the dev instances of Integration, Visual Builder, and whatever else supports it, all sharing the dev identity domain.

·        A pre-production compartment that mirrors it, and a production compartment that mirrors that.

·        Integrations, extensions, and configuration promoted through those environments the way you would expect.

Oracle was candid that most long-standing customers, us included, do not look like this, because services were provisioned at different times for reasons that made sense then. It is a target state, not a judgment on anyone's current state. Getting from here to there is its own conversation, and one Oracle offered to work through with us.

Everything Oracle runs is on OCI

One comment reframed things for a few people in the room. We tend to talk about moving PaaS "into the same OCI as Fusion" as if Fusion recently arrived there. It did not. Fusion has run on OCI for a long time, as does essentially everything Oracle offers, homegrown or acquired.

What has changed is visibility. Services are progressively surfacing in the Oracle Cloud console at cloud.oracle.com, which is the console for all of Oracle Cloud rather than only infrastructure. When people say "OCI" they usually mean compute, storage, and networking. The console is that, plus PaaS, plus SaaS, and Oracle's direction is that everything you subscribe to shows up there.

It also explains how so many of us ended up with split tenancies. Fusion pods originally existed without any tenancy at all. You signed a contract and consumed your environments from their URLs. When tenancies were introduced a few years ago to give customers a way to manage everything, Fusion pods were attached to one, and PaaS services bought earlier often lived in another.

A tenancy is a box, on purpose

The question our team was most eager to ask: could we simply move things between tenancies to consolidate?

The short answer is no, and the reason is a good one. When a tenancy is created, keys and certificates are generated for it and held in hardware security modules. Tenancies are a hard partition, and Oracle has intentionally not built tooling to move resources from one to another. A compute instance, a block volume, an Integration instance, a Fusion pod: whatever is created in a tenancy stays in that tenancy.

What you can do is rebuild and migrate:

·        Export and import configuration, such as Integration projects, users and groups, and API gateway definitions.

·        Use Terraform to recreate infrastructure and the PaaS service instances themselves.

·        Use the standard environment migration and refresh tooling where it applies.

Plan for the fact that a rebuilt instance is a new instance. It will have a new URL, and anything that pointed at the old one needs to change.

I appreciated the framing. A tenancy is a box that things can come into and go out of, but cannot slide sideways between. Once you accept that, "move" stops being the right word, and the real questions become whether a rebuild is worth it and where the new thing should be born.

Where new subscriptions land

That leads to the most practical takeaway I would pass to anyone buying something new from Oracle.

When you subscribe to a new Fusion service, the person who placed the order receives an activation email. It asks where you want the service to go: an existing tenancy, or a new one.

Expanding an existing subscription is different. If you have three pods and add two more, the new ones are provisioned alongside the existing ones in the same tenancy.

Oracle's direction is that SaaS services live in a tenancy. For a specific product, confirm how activation works before you assume. Oracle sells a lot of SaaS, and not every service follows exactly the same path today.

My advice is to treat that activation click as an architecture decision, not an administrative step. Decide where a new service belongs before the email arrives. We have made that call deliberately in the past, including once choosing a new, isolated tenancy on purpose, and I was glad we had talked it through first.

So, one tenancy or many?

Oracle's position was balanced. You can put everything in one tenancy, and for a smaller organization a single tenancy is ideal. There are also legitimate reasons larger enterprises do not:

·        Business units that operate independently, or could be divested someday. Separating a tenancy after the fact is hard, so if a unit might leave, it probably belongs in its own.

·        Administrative separation, where different groups need clearly distinct control.

The counterpoint Oracle offered is the one I keep coming back to. If it is your HR system and everything that supports it, and you are buying it from Oracle, it makes sense to keep it together unless you have a specific reason not to. The same applies to ERP.

A separate tenancy also comes with work. A few things our team noted you take on:

·        Network connectivity. A new tenancy does not automatically share your existing FastConnect. Remote peering or a hub-and-spoke design can bridge it, but it has to be designed.

·        Identity wiring. Inside one tenancy, the same identity flows naturally across Fusion, Integration, analytics, and the rest of an environment. Across tenancies, you build and maintain that federation yourself. This matters more every release, especially as capabilities like AI Agent Studio span product families and benefit from a common identity.

·        Commercial alignment. Subscriptions and credits are associated with a tenancy, so how you consume services in a new one is a conversation for your account team.

A word on identity domain types

One more piece helps explain the design. The Default domain in a tenancy is a Free domain type intended for managing the tenancy, and its user limit reflects that purpose. The identity domain delivered with a Fusion pod is an Oracle Apps domain type, provided as part of the Fusion subscription. It covers what your users need to access Fusion and the services supporting it in the same tenancy.

If you still carry bring-your-own licensing assumptions from older IDCS or on-premises identity deployments, it is worth revisiting them. For the Fusion use case you may not need them. If you plan to use a Fusion identity domain well beyond supporting Fusion, have that licensing conversation with your account team up front.

What I am taking away

·        Design toward the target state: one tenancy per logical platform, compartments per environment, and supporting PaaS provisioned against the same identity domain as the Fusion pod it supports.

·        Stop saying "move." Resources do not move between tenancies. Plan rebuilds with export, import, and Terraform, and plan for new URLs.

·        Decide where new services land before the activation email arrives.

·        Create a new tenancy when there is a genuine boundary, such as an independent or divestible business unit, and budget for the networking, identity, and commercial work that comes with it.

·        Keep identity consistent within each environment. The more your Oracle products work together, the more that pays off.

We closed the session with a standing offer from Oracle to go deeper on specifics once we have worked out what we want our architecture to achieve. That is the next step on our side, and I will share what we learn.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.

How I Built an Oracle AI-Driven Support Tool for Oracle Cloud Using Databricks, OCI and Claude

If you've spent any time supporting Oracle Cloud ERP, HCM, or EPM, you already know the pattern. A user submits a ticket about a payroll element not processing. You ask a series of diagnostic questions. You identify whether it's an effective date problem, a payroll cutoff issue, a security profile gap, or one of a dozen other root causes. You document the fix. Two months later, a different user hits the same issue and the whole cycle starts over.

This post walks through a tool I built to break that cycle. It is called Solution Designer, and it uses an agentic AI approach on top of Databricks to give your Oracle support team structured, consistent, context-aware troubleshooting guidance -- without requiring users to know exactly what to ask.

The Problem With Generic AI for Oracle Support

The first instinct most teams have is to point users at a general-purpose chatbot. "Just ask it your Oracle question." The problem is that Oracle Cloud is enormous and deeply configuration-dependent. A question like "why isn't my payroll processing?" has radically different answers depending on element type, entry method, effective date, pay period status, and whether payroll has already been run for the period.

A generic chat interface puts all of that burden on the user. They have to know which details matter, phrase the question precisely, and interpret an answer that wasn't tuned to their specific setup.

I took a different approach. Instead of a free-form chat interface, I built a guided intake flow that collects the right diagnostic signals before the AI ever generates a response. The model then has full context to produce a solution that actually fits the situation.

What Solution Designer Does

At its core, the tool is a Flask application deployed as a Databricks App. It connects to OCI or Claude via the Databricks Foundation Model API or the OCI LLM API. The experience works like this:

1. The user picks a scenario from a categorized library. The library currently covers 31 Oracle scenarios across ERP (Payables, Procurement, Receivables, General Ledger, Fixed Assets, Inventory, Projects), HCM (Payroll, Absence, HCM Data Loader, Fast Formula, Security, Workforce Compensation), EPM (Consolidation, Planning Data Loads, Rule Troubleshooting), and integrations (REST API, FBDI, BI Publisher, OTBI, Workflow Notifications).

2. The tool presents a structured intake form specific to that scenario. For Payroll Element Entries, for example, the user answers eight targeted questions: what type of element, how it was created, the specific symptom, how many employees are affected, the effective date, the pay period, whether payroll has already run, and the current status of the element entry. Every question has help text explaining why it matters.

3. The scenario definition includes edge cases. Each scenario JSON file encodes known Oracle gotchas as conditional logic. If the effective date falls outside the pay period, the system flags that as a high-severity edge case and incorporates it into the prompt context automatically. If payroll already ran and the entry is still unprocessed, the tool knows to surface the rollback-or-next-period decision. Users do not have to discover these traps manually.

4. OCI or Claude generates a tailored solution. With the structured inputs and edge case context loaded, OCI/Claude produces a step-by-step resolution path that is specific to what the user actually described. This is not a generic knowledge article. It is a direct answer to their exact configuration.

5. The user can refine through follow-up questions. After the initial solution, the conversation stays open. Users can ask clarifying questions and the system maintains full session context so responses stay coherent. Sessions persist in a Unity Catalog Delta table so the conversation survives page refreshes and can be resumed later.

6. After rating the solution, the user can generate a training document. Once the problem is solved and the user rates the response, a "Generate Training Doc" button appears. They specify a format (Markdown, slide outline, or quick-start guide) and a target audience, and OCI/Claude turns the solution into a shareable knowledge artifact. This is where individual troubleshooting events compound into reusable organizational knowledge.

How the Knowledge Base Works

Each scenario is a JSON file that defines intake questions, answer options, help text, edge cases, and the conditions that trigger them. Here is a simplified example from the Payroll Element Entries scenario:

```json

{

  "id": "oracle-hcm-payroll-element-entries",

  "category": "Oracle HCM",

  "title": "Payroll Element Entries Not Processing",

  "intake_questions": [

    {

      "id": "effective_date",

      "question": "What is the effective date of the entry?",

      "type": "text",

      "required": true,

      "help_text": "Enter date in format MM/DD/YYYY - must be within pay period"

    }

  ],

  "edge_cases": [

    {

      "condition": "effective_date outside of pay_period",

      "impact": "Entry will not process in expected period. Must match effective date to pay period or entry will be skipped.",

      "severity": "high"

    }

  ]

}

```

This structure means the expertise lives in the JSON, not in the prompt. Adding a new scenario or a new edge case is a file edit, not a code change. The knowledge base hot-reloads, so updates go live without a restart.

The Architecture on Databricks

Running this on Databricks was a deliberate choice. The team already uses the platform, so authentication, security, and data governance come for free. Here is the technical stack:

- Databricks Apps for hosting the Flask application

- Databricks Foundation Model API to call Claude (Sonnet 4.5 at time of writing) without managing any external API credentials or you can use the OCI LLM API and connect to it using Python from within the solution

- Unity Catalog Delta tables for two purposes: structured logging of every interaction to `ef_dv.raw_dev_metadata.solution_designer_logs`, and session persistence in `ef_dv.raw_dev_metadata.conversation_sessions`

- Serverless SQL Warehouse for querying those Delta tables from the app

- On-behalf-of (OBO) authentication so every request to Databricks runs under the identity of the actual user, not a shared service account

The logging design deserves a mention. Every time a user generates a solution, submits feedback, or asks a follow-up question, a structured record lands in the Delta table with fields for user identity, scenario ID, scenario category, satisfaction rating, time saved, duration, and the interaction text. That gives leadership a real ROI dashboard backed by queryable data rather than estimates.

How We Built This With Agentic Development

The development process itself is worth describing because it reflects a pattern that works well for Oracle-specific tooling.

We used GitHub Copilot in agent mode throughout the build. The agent did not just autocomplete code; it was given feature requirements and asked to reason through the implementation, identify edge cases in its own output, and iterate. The key discipline was keeping the agent's scope narrow. Each session had one focused objective: add session persistence, add the feedback loop, fix a specific datetime bug in Delta table reads, resolve an issue with the resume-session banner showing stale state.

This approach works well for Oracle support tooling for a specific reason: Oracle Cloud problems are well-bounded. The diagnostic questions for a 3-way match hold resolution are not the same as the diagnostic questions for an HCM Fast Formula error. That domain specificity is an asset when working with an AI coding agent because you can describe the scenario structure precisely and the agent can reason about it correctly.

The iterative cycle looked like this:

1. Identify a gap in the user experience (example: returning to a previously solved scenario still presented the rating form instead of the completed state).

2. Trace the root cause through the code. In this case, the `/feedback` endpoint stored the rating on the session's last interaction in the Delta table but intentionally left session status as `active`. The frontend never checked whether the last interaction already had feedback attached.

3. Write a targeted fix. The solution was a new `restoreFeedbackStateFromHistory()` function in the frontend that reads the persisted rating, locks the feedback buttons, skips the rating form, and surfaces the "Generate Training Doc" button directly. No backend changes needed.

4. Run the 329-test suite to verify no regressions.

5. Deploy with the PowerShell script that syncs files to the Databricks workspace and triggers a new app deployment.

6. Confirm SUCCEEDED in the Databricks Apps deployment status.

The agent accelerated every step but did not replace the domain judgment calls. Decisions like "should the session status flip to solved when feedback is submitted, or should we leave it active so users can keep the conversation going?" require understanding the Oracle support workflow. The agent implements whatever direction you give it; you still have to give the right direction.

What This Looks Like in Practice

Consider a real scenario: an Oracle Finance team is getting 3-way match holds on vendor invoices. Previously, a ticket would come in, a knowledgeable team member would spend 15 to 45 minutes asking diagnostic questions via email or a Teams chat, and then write up a resolution.

With Solution Designer, the user navigates to the "3-Way Match Hold Resolution in Payables" scenario. They answer questions about hold type (quantity vs. price variance), tolerance settings, receipt status, PO type, and approval status. The tool detects relevant edge cases -- for example, if it is a price variance hold on a blanket PO, there is a specific Oracle behavior around line-level vs. header-level tolerances that trips people up repeatedly. The solution it generates addresses exactly that combination. If the user is satisfied, they rate the response, click "Generate Training Doc," specify their audience as "Oracle Finance users," and download a formatted guide they can drop into their SharePoint or Confluence space.

The time saved compounds across every person who hits that scenario going forward.

Click on the Images to Expand Them~

What We Learned

A few things stand out after building this:

Structure beats prompting. The quality improvement from giving AI structured inputs with pre-evaluated edge cases is larger than any prompt engineering trick. When the model knows that the effective date is outside the pay period because the scenario definition explicitly flagged it, the response is categorically more useful than when the user tries to describe that situation in free text.

Persistence changes the support dynamic. When solutions survive as resumable sessions in Delta, the tool stops being a one-shot query tool and starts being a case management layer. Users come back to the same session when a problem resurfaces, add follow-up context, and build a richer record of what was tried and what worked.

Feedback closes the loop. The satisfaction ratings and time-saved estimates that land in the Delta log are not vanity metrics. They identify which scenarios are working and which ones need better edge case coverage. The scenarios with low success rates are the ones that need a knowledge base update. That is a tractable engineering task.

Domain expertise encodes well into JSON. Oracle Cloud has well-documented configuration patterns and well-known failure modes. That knowledge, once captured in the scenario JSON format, is reusable forever. An experienced Oracle consultant or admin can encode years of diagnostic heuristics in an afternoon and make them available to everyone on the team immediately.

Getting Started If You Want to Build Something Similar

The approach is not specific to this stack. The core pattern is: structured intake + knowledge-encoded edge cases + LLM synthesis + persistent sessions. You need:

- A way to call a capable LLM (Databricks Foundation Model API, OCI LLM, Azure OpenAI, or similar)

- A JSON or database structure to encode your domain knowledge

- A lightweight web framework (Flask works well; FastAPI is another good option)

- A persistence layer for sessions and logs (Delta on Databricks is convenient if you are already there; a Postgres database works just as well and of course OCI Autonomous Databases!)

If your organization runs Oracle Cloud and has people who have been troubleshooting it for years, you already have the hardest ingredient: the domain knowledge. The tool just gives you a way to make it available at scale.

The knowledge base for this project started with five scenarios based on the most frequent support tickets. It now covers 31. Each new scenario takes roughly two to four hours to build out properly, including the edge cases. That is a reasonable investment for a scenario that generates 20 support tickets a month.

If you are building something similar for your Oracle user community, the questions, edge case structures, and session management patterns described here translate directly. The specific scenarios are where your team's expertise goes -- everything else is scaffolding.

AI Enhances Oracle Cloud HCM Support: Elevating Insight with the Oracle HCM Intel CLI

Oracle Gen AI + Public HCM Metadata = Limitless Insight

The Oracle HCM Intel CLI Tool is a professional-grade command-line assistant that uses your extracted HCM metadata and combines it with the capabilities of Oracle’s OCI Generative AI service (powered by Cohere) or OpenAI, or the LLM of your choice, giving you intelligent insights relative to HCM data structures. And it's all done securely and locally—no sensitive data leaves your environment.

By referencing public HCM data definitions, this project demonstrates just how powerfully Oracle Gen AI, and other AI offerings, can be applied in the enterprise to support analysts, developers, and architects with tasks such as:

• Generating SQL queries based on natural language
• Suggesting joins between key Oracle HCM tables
• Explaining and optimizing existing SQL
• Creating BI Publisher-ready templates
• Performing semantic metadata searches

Project GitHub: oracle_hcm_intel_cli

Demo: Watch Demo

---

Built With Practical Enterprise Needs in Mind

The tool includes features that any real-world implementation would benefit from:

• Encrypted .env handling using runtime secrets
• Markdown output for reporting or Copilot/Teams usage
• Audit mode for logging what metadata was passed to the LLM
• Modular provider support for OpenAI or Oracle Gen AI
• Interactive prompt chaining for analysts and non-developers

It’s optimized for real users working in real environments—offering flexibility without sacrificing security or precision.

---

Powered by Oracle Technology, Honoring Oracle’s Vision

This CLI tool is powered by Oracle’s own public documentation and showcases the capabilities of Oracle Cloud Infrastructure’s Generative AI platform. It's a clear example of how AI and metadata can be responsibly applied in the enterprise, especially when building tooling around Oracle’s HCM ecosystem.

Oracle’s Gen AI service is the star of the show here—it brings context, comprehension, and creative query generation to the hands of business users and technical professionals alike.

Earlier this month, I introduced a Metadata Extractor CLI Tool built to programmatically parse Oracle Cloud HCM’s public documentation and extract table and view metadata into JSON format. That foundational tool—available on GitHub at oracle_hcm_metadata_extractor—has enabled this powerful second act: the Oracle HCM Intel CLI.

---

Get Started

1. Extract metadata using: oracle_hcm_metadata_extractor

2. Query and explore with: oracle_hcm_intel_cli

Whether you’re working in HCM data architecture, reporting, or support—this is your AI-powered sidekick.

---

I hope this project inspires others to build upon Oracle’s cloud platform and apply Generative AI responsibly. The future of enterprise tooling is intelligent, secure, and deeply integrated—and with Oracle Gen AI, that future is now.

—
Julio @ OracleSpot.net

Leveraging Oracle Cloud’s Generative AI with Cohere: A Hands-On Approach

After days of tinkering and fine-tuning, I'm excited to share something I’ve been working on — OCI Generative AI Cohere Integration with external services. If you're someone who works with AI, Oracle Cloud, or just enjoys diving into new tech, this project might be something you'll find interesting.

What's the Project About?

In short, it's a simple yet powerful integration of Oracle Cloud’s Generative AI service with Cohere's language model by exposing it to external usage in order not to be confined to the chat experience within the OCI console. The goal is to provide an easy-to-use interface for AI-driven responses via a Flask API or function-based approach. Whether you're running the service locally or integrating it into your own applications, this project is meant to be a starting point for building smarter, AI-powered experiences that allow you the flexibility of using your preferred development platform outside of the playground in your Oracle OCI Tenancy.

Why This Project?

If you’re like me, you enjoy playing with new tools but don’t always want to reinvent the wheel every time you build something. That’s why I wanted to simplify integrating Oracle's powerful AI services into everyday applications. The project takes the heavy lifting out of the process and provides a clean, easy-to-use API for interacting with Oracle’s AI models.

But it doesn’t stop there. Whether you're building out something bigger or just playing around with ideas, this project is designed to be flexible and easily extendable.

Here’s What You Get:

• Flask API: If you’re building a web-based application and want easy interaction with the Generative AI service, the Flask API is ready to go. You can send requests, get responses, and scale up as needed.
• Function-based API: For those who don’t need a full web API, you can call the AI service directly from a function that you can import into your Python projects. Perfect for smaller integrations or experimenting within your own apps.
• Configuration Flexibility: With environment variables and a configuration file, you have full control over things like model parameters and Oracle Cloud credentials.

How to Use It?

1. Set up your environment: Whether you're using the Flask API or the function-based setup, you’ll need to configure your environment with Oracle Cloud credentials and some basic settings.
2. Get running: Once configured, you can easily call the API or function with any message you want to send to the AI model, and you’ll get a detailed response in return.

I’ve added full instructions on the project’s GitHub page, including setup steps, environment variables, and how to run both approaches.

What’s Next?

The goal is to keep expanding this project. Right now, it’s all about integration, but as AI services evolve, I want to keep adding new features and I likely will build apps that consume these interfacing endpoints in order to use the power of the Cohere LLM. Expect more updates on this as I add new functionality and more tutorials to help everyone get the most out of the platform.

Feel free to dive into the project, contribute, or just ask questions. I’m always happy to connect with fellow developers who are exploring AI and Oracle Cloud.

Check it out on GitHub: OCI Generative AICohere Integration

I've added some screenshots below showing the interactions with the OCI Gen AI service via Postman by utilizing the Flask API, allowing extensibility outside of the chat experience in OCI which is the default experience. 

By utilizing the API approach you can take advantage of the power of the Cohere LLM through Oracle OCI in your applications and data science tools while maintaining your security assurances of being inside of your OCI tenancy.

Thanks for reading, and happy coding!

OCI Gen AI Playground

Click on the images to expand them for ease of viewing

Postman Interaction with Flask API Exposing the OCI Gen AI Chat Service

OCI Gen AI Traffic from the API