Initial Fusion Implementation Users
Purpose
Use this skill to create an initial implementation user in a greenfield Oracle-managed Fusion 26B SaaS environment. The default role plan is grounded in Oracle's Functional Setup Manager Roles and Allowed Activities mapping and assigns only the role necessary for the listed activities.
Required Inputs
For every run, prompt for:
usernameuser_emailproject_id, unless a project is already selected
Required Reference
Before planning or executing, read:
references/oracle-26b-hcm-implementation-users.md- Oracle 26B
Mapping of Setup Activities and Required Roles, sectionRoles and the Allowed Activities, for the minimum role required to perform the listed activities.
Workflow
- Generate a plan with
scripts/prepare_implementation_user_plan.py. - Run read-only preflight against the target pod before any write:
- verify the target user does not already exist, or get update approval
- resolve the required job role
- resolve every planned implementation-user job role
- Ask for explicit write approval with the resolved plan.
- Execute the setup sequence:
- run
Retrieve Latest LDAP Changes - run
Import Users and Roles into Application Security - create the implementation user with associated person type
None, user categoryDEFAULT, active status, email, and username - assign the planned implementation-user job roles
- run
- Validate Security Console role membership and implementation user access.
REST Execution Support
Use scripts/execute_implementation_user_plan.py to execute supported REST
steps through core.fusion-api.rest-api-client.
The executor creates users through:
/hcmRestApi/scim/Users
The executor assigns roles through:
/hcmRestApi/scim/Roles/
The executor is conservative:
- dry-run is the default
--live-preflightresolves the target user and every planned role without writing; execution repeats that role-resolution gate before creating a user--executerequires--confirm-create-user- if the user already exists, execution stops instead of overwriting it
- final role assignments are resolved through the SCIM Roles endpoint and added to the role membership after the user is created
- roles with a planned
ORA_identifier are resolved by SCIM rolenameusing that planned role code, not by display name - every planned job role must pass the
ORA_planned-identifier check using the SCIM rolename - if the user already exists, use
--assign-roles-to-existingto assign the planned roles to that user without recreating it - use
--include-roles-in-user-bodyonly for pods that explicitly accept SCIMrolesvalues in the/Userscreate body - Security Console-only or environment-specific setup remains listed as manual follow-up in the audit
Role Policy
Oracle 26B Functional Setup Manager Roles and the Allowed Activities
grounding establishes the minimum role necessary to perform the listed
activities:
Application Implementation Consultant(Job)
Role-selection logic:
- Use the Oracle
Roles and the Allowed Activitiessection as the controlling source for the minimum Functional Setup Manager role grant. - Select
Application Implementation Consultantbecause that role covers the full listed activity set for an implementation user: reviewing and configuring offering features, performing all setup tasks, managing setup data through offerings, functional areas, and implementation projects, export/import, comparison, setup data reports, export/import process submission and monitoring, implementation project management, and managing integration of additional applications. - Do not add
Application Implementation Manager; Oracle lists it for a smaller activity set and it does not cover all setup tasks and setup data management. - Do not add
Functional Setups User; Oracle positions it for specific setup tasks and requires a separate role with task-specific privileges. - Do not add
Export Import Functional Setups User; Oracle positions it for export/import, comparison, and report activities and requires theFunctional Setups Userrole plus task-specific setup data privileges. - Add the configured IT Security Manager and Application Diagnostic Administrator job roles because this implementation-user policy explicitly requires them. Do not add further product, HCM, payroll, compensation, data, security-profile, or role-mapping grants unless a later, separate project-specific scope analysis explicitly identifies them as necessary.
Do not treat listed privileges, such as Manage Setup Migration Settings or
Manage Third Party Applications, as roles. Capture them as possible
task-specific privilege requirements if the project later narrows the
implementation user's scope.
At execution time, enforce planned ORA_ role identifiers from the plan. Any
role with a planned identifier such as roleCode, code, name, or value
starting with ORA_ must be resolved from /hcmRestApi/scim/Roles with
filter=name eq "{ORA_ROLE_CODE}". Do not resolve those roles by display name
because Fusion can expose different non-ORA roles with the same display name.
Roles without a planned ORA_ identifier may be resolved by display name.
Role grants assigned when creating the implementation user:
Application Implementation Consultant(ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB)IT Security Manager(ORA_FND_IT_SECURITY_MANAGER_JOB)Application Diagnostic Administrator(ORA_FND_DIAG_ADMINISTRATOR_JOB)
Application Implementation Consultant remains the minimum Functional Setup
Manager role. The IT Security Manager and Application Diagnostic Administrator
grants are explicit implementation-user role-policy additions and must be
preflighted and approved with the same user-create payload.
Stop Conditions
Stop before write when:
- the user exists and update behavior is not approved
- any required role cannot be resolved in the target pod
- the user has not approved the resolved write plan
Commands
Preview plan:
bashpython3 core/getting-started/implementation-users/scripts/prepare_implementation_user_plan.py \ --username "{username}" \ --email "{email}" \ --project-id "{project_id}" \ --output project/{project_id}/artifacts/core/getting-started/implementation-users/current/{username}_implementation_user_plan.json
Execution plan:
bashpython3 core/getting-started/implementation-users/scripts/prepare_implementation_user_plan.py \ --username "{username}" \ --email "{email}" \ --project-id "{project_id}" \ --execution-mode execute \ --output project/{project_id}/artifacts/core/getting-started/implementation-users/current/{username}_implementation_user_plan.json
Dry-run the REST executor against a generated plan:
bashpython3 core/getting-started/implementation-users/scripts/execute_implementation_user_plan.py \ --plan project/{project_id}/artifacts/core/getting-started/implementation-users/current/{username}_implementation_user_plan.json
Execute supported REST calls after explicit approval:
bashpython3 core/getting-started/implementation-users/scripts/execute_implementation_user_plan.py \ --plan project/{project_id}/artifacts/core/getting-started/implementation-users/current/{username}_implementation_user_plan.json \ --execute \ --confirm-create-user
Only the documented relative /hcmRestApi/scim/Users and /hcmRestApi/scim/Roles
collections are allowed; absolute endpoint overrides are rejected even on the
standard host. The wrapper selects standard-Fusion context and --scim-only,
validates destinations before login and sending, and rejects write redirects.
Lookup failures stop execution; --allow-create-after-preflight-error is rejected.
Passwords stay in Fusion reset/enrollment and must never enter a plan, body or log.
The managed token cache stays outside the checkout. SCIM field mappings remain
configurable through:
--user-query-field--user-key-field--role-query-field--role-key-field
Validation
Report:
- setup task codes used
- user creation status
- assigned
Application Implementation Consultant,IT Security Manager, andApplication Diagnostic Administratorroles - active user status


