An Oracle Fusion data access comparison can help investigate why one user can work with a business unit and another cannot. In Fusion Toolkit’s 3.2.0 preview, ask AI Administrator to compare the users’ active Financials assignments, explain the differences, and inspect role assignments separately. The comparison provides evidence for a decision; it does not establish effective access or authorize permission changes.
Synthetic illustration: The prompts, users, role, and business units below are examples, not a recorded session or actual access results. Use dedicated existing test accounts for your own investigation.
Run it directly from the CLI
You can compare the same users directly in a terminal without an AI agent. Use the matching Fusion Toolkit 3.2.0 preview, a valid licence, and the existing security-test profile with administrative view access to Financials assignments. Open Bash or WSL in the installed fusion-toolkit-ai-administrator folder, with fusion-toolkit on your PATH. The ai-admin command group executes these reads directly; no model session is started. Both users are read through the same profile and administrator account.
Compare active assignments in both directions
Create explicit filters for the existing source and target test users. ActiveFlag=true keeps both sides scoped to active assignments:
fusion-toolkit --version
fusion-toolkit ai-admin docs status
cat > access-comparison-parameters.json <<'JSON'
{
"source_filter": "UserName='FTK_SOURCE_TEST';ActiveFlag=true",
"target_filter": "UserName='FTK_TARGET_TEST';ActiveFlag=true"
}
JSON
fusion-toolkit --profile security-test --output json \
ai-admin api execute --recipe access-grant-comparison \
--parameters access-comparison-parameters.json \
> access-comparison.json
python3 -m json.tool access-comparison.json
Replace the synthetic usernames with exact existing test accounts. Check the exit status and result’s exit_code, status, environment, and origin before drawing conclusions. The output contains source and target read evidence under data.steps, plus data.outputs.source_only and data.outputs.target_only. These difference lists compare RoleCommonName, SecurityContext, and SecurityContextValue. Shared combinations appear in neither list; the original rows remain in the step evidence.
Check the comparison’s limits
Each side permits zero through 100 returned assignments. A failed, truncated, or over-limit read prevents a complete comparison. An empty list can reflect the filter, username, or administrator’s visibility. Inspect SecurityContextValue2 and SecurityContextValue3 in the original rows when the context has multiple components; they are not part of the three-key difference calculation. Narrow both filters consistently if you add a role or context restriction.
Read each user’s direct roles separately
Run the user-access lookup for both accounts and keep the results distinct:
fusion-toolkit --profile security-test --output json \
ai-admin user-access get --username FTK_SOURCE_TEST \
> source-user-access.json
fusion-toolkit --profile security-test --output json \
ai-admin user-access get --username FTK_TARGET_TEST \
> target-user-access.json
python3 -m json.tool source-user-access.json
python3 -m json.tool target-user-access.json
This lookup can aggregate visible HCM or identity-service direct roles and Financials assignments. Inspect its per-section completeness and errors; one available source cannot fill an inaccessible role section. It does not certify all inherited roles or effective access. The comparison and both lookups are reads and do not copy, add, or deactivate grants.
Use the returned differences and original rows to prepare the same investigation handoff described below. A source-only assignment is evidence for discussion, not an instruction to grant it. Verify the original business task separately and use a new reviewed plan if a permission change is justified.
The AI Administrator walkthrough below explains the same comparison and follow-up questions conversationally.
Start the conversation with a clear scope
Start a compatible agent, such as Codex, Claude Code, or Gemini CLI, with the installed AI Administrator workspace as its working folder. It should read the bundled instructions and use the matching 3.2.0 preview Toolkit. You need a valid Toolkit licence and an existing configured Oracle profile. Keep credentials out of chat.
Here, security-test is the non-production profile, FTK_SOURCE_TEST is the reference user, and FTK_TARGET_TEST is the user under investigation. These names do not instruct the assistant to create accounts. Have it identify the profile’s declared environment, site address, and Oracle account before querying.
Begin with:
In security-test, compare the active Financials data assignments for FTK_SOURCE_TEST and FTK_TARGET_TEST without changing permissions. Use FTK_SOURCE_TEST as the reference and show differences in both directions.
The assistant should find the documented comparison workflow and check its documentation freshness. If it uses cached documentation while offline, it should disclose the retrieval date.
The configured account needs administrative view privileges for these Financials assignments. Role investigation may need separate access to HCM user accounts or the identity service. Missing read access should be reported so the administrator can address the specific gap.
Understand which question the comparison answers
Financials data assignments and role assignments are related, but answer different questions. A role contributes functional privileges. A data assignment connects a user and role with a security context, such as a business unit.
Oracle’s Assign Data Access to Users guidance treats job-role assignment and data-access setup as separate tasks. Two users with the same role name may have different data scopes. A data-assignment row alone does not establish every privilege needed for a task.
The comparison reads the Financials assignments described in Oracle’s Get all data assignments by user and role reference. Both reads use the same profile, environment, and administrator’s view. This is not a comparison across different Oracle environments or a translation of business-unit identifiers between them.
AI Administrator should explicitly select active assignments for both users. If the question concerns a particular role or context, narrow both sides consistently. See turning Oracle REST documentation into administration workflows for how these documented reads form a reusable workflow.
Explain differences without inferring changes
Follow up with:
Explain the assignments found only for the reference user, those found only for the target user, and the combinations present for both. State the comparison criteria and anything that could make the result incomplete.
The preview comparison uses three values: the role’s common name, the security context, and its first context value. For a business-unit assignment, that means comparing the role, the business-unit context, and the selected business unit.
Consider this hypothetical input, supplied only to illustrate interpretation:
| User | Role common name | Security context | Context value |
|---|---|---|---|
| FTK_SOURCE_TEST | FTK_AP_REVIEWER | Business unit | FTK Demo Zurich |
| FTK_SOURCE_TEST | FTK_AP_REVIEWER | Business unit | FTK Demo Geneva |
| FTK_TARGET_TEST | FTK_AP_REVIEWER | Business unit | FTK Demo Zurich |
| FTK_TARGET_TEST | FTK_AP_REVIEWER | Business unit | FTK Demo Rome |
For those hypothetical rows, Geneva would appear only for the reference user and Rome only for the target. Zurich would appear in neither difference list because the three-value combination is shared. The assistant can explain shared combinations from the returned evidence; the difference lists themselves contain only differences.
This would support a limited conclusion about the returned assignments. It would not establish that Geneva should be granted or Rome removed. The users might have different responsibilities and approved scopes. Naming one account as the reference does not make its permissions the desired template.
Check visibility and additional context values
Ask:
Were both users’ assignments fully retrieved within this comparison’s limits? Check for additional security-context values that the comparison did not include.
Each side of the preview comparison permits zero through 100 returned assignments. A truncated, over-limit, or failed read prevents a complete comparison. Resolve that limitation or narrow the investigation before drawing conclusions from the difference lists.
An empty set needs care. Check the username, active-only scope, selected profile, and the administrator’s visibility. It does not prove that the account has no access through another resource or security mechanism.
Some security contexts have multiple components. The comparison does not include the additional fields named SecurityContextValue2 and SecurityContextValue3. Inspect all relevant components separately before treating rows as equivalent. Missing or unexpected role or context fields also limit interpretation.
Active status is not one of the three comparison values either. Selecting active assignments explicitly keeps this example focused. A broader comparison could conceal an active/inactive distinction unless the assistant checks that field separately.
Inspect role assignments as a separate read
Continue with:
Inspect the visible direct role assignments for both test users separately. Explain which account, role, and Financials assignment information was available, and label every unavailable or partial section.
The assistant can use the user-access lookup to collect visible direct roles from HCM user accounts or the identity service, alongside Financials assignments. It should resolve the exact user and explain completeness for each section.
One source may be inaccessible while another returns rows. A successful Financials read cannot fill a missing role section. A section reported as complete means that resource was retrieved within its bounds; it does not certify the user’s entire effective access.
The lookup does not traverse every inherited role, certify HCM security profiles, or test the user’s application session. Follow up in Security Console and reproduce the reported task with the appropriate test account and business data when authorized. Distinguish permission evidence from a demonstrated ability to perform that task.
Turn the investigation into a reviewed decision
A useful final request is:
Summarize what explains the reported access difference, what remains uncertain, and what business approval would be needed before considering a permission change.
The handoff should name the environment and administrator account, exact users, active-only scope, retrieval time, returned differences, additional context checks, role findings, and visibility limits.
If a change is warranted, prepare a separate plan for the exact grant or deactivation. Before asking for approval, the assistant must display the complete current plan: environment, site address, Oracle account, target and exact action, current state with secrets hidden, proposed role and context values, impact, recovery guidance, documentation source, release and checksum, verification limits, and plan reference, fingerprint and expiry. Approval of that plan must come afterward; a comparison request never authorizes copying access.
After an approved change, reread the assignment and verify the original business task separately. The human approval workflow explains this transition. Start with the AI Administrator overview to prepare your own bounded comparison.