# Oracle E-Business setting "disableInitializeSession": false causing errors

**URL:** <https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988>\
**Category:** SHF Discussion and Questions\
**Tags:** identity-security-cloud\
**Created:** [March 9, 2026, 6:17pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988 "2026-03-09T18:17:26Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikenawara](https://avatars.discourse-cdn.com/v4/letter/m/aca169/32.png) [@mikenawara](https://developer.sailpoint.com/discuss/u/mikenawara)\
**Post date:** [March 9, 2026, 6:17pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/1 "2026-03-09T18:17:26Z")

</div>

> ‼ Please be sure you’ve read the [docs](https://developer.sailpoint.com/idn/docs/) and [API specs](https://developer.sailpoint.com/idn/api/getting-started) before asking for help. Also, please be sure you’ve [searched](https://developer.sailpoint.com/discuss/search?expanded=true) the forum for your answer before you create a new topic.

## Please consider addressing the following when creating your topic:

- What have you tried? Provisioning\disabling accounts work just fine when “disableInitializeSession”: is set to true but shows as “anonymous” for audits. After testing out the Additional settings Audit Username for Oracle EBS source and setting this to false per SailPoint’s recommendations it is now failing.

- What errors did you face (share screenshots)?

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/b/3/b340d48f29f98db001472cde3861f2d14d0f671e.png)

- Share the details of your efforts (code / search query, workflow json etc.)?
- ![image](https://global.discourse-cdn.com/sailpoint/original/3X/a/0/a033bd856e9c0a961ecb2561bf3f091933037646.png)
- What is the result you are getting and what were you expecting? We are getting errors so no provisoning\deporvisioning or entitlement changes are happening. What we expect is for all of this to happen and for the additional feature for assigning a service account for auditing to show as the account making the changes.

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/f/3/f3e97bbfa415b87009d86cf44a8dfab49a3c5723.png)

---

<div class="post-metadata">

**Author:** ![raeannehinkens](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@raeannehinkens](https://developer.sailpoint.com/discuss/u/raeannehinkens)\
**Post date:** [March 9, 2026, 7:07pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/2 "2026-03-09T19:07:08Z")

</div>

I’m a DBA assisting Mike with this issue. We noticed that Sailpoint’s documentation does not say to assign any EBS responsibilities to the **FND\_USER** account _(ex. SRVC.SAILPOINT below)._ How does this account then get permissions to modify EBS users instead of the ANONYMOUS user that it does without the **Audit User Name** setting in Sailpoint? We tried to assign **System**  **Administrator** to the EBS account, but that did not fix the FND\_USER\_PKG error above. _Sailpoint Document Link: [Additional Settings](https://documentation.sailpoint.com/connectors/oracle/ebusiness_suite/help/integrating_oracle_ebs/additional_settings.html)_

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/7/e/7e18629b4824f1c7da48bccc9449866e11185d1c.png)

We think there might be some missing setups to this account since it should not be trying to use the APPS.FND\_USER\_PKG (seeded from oracle), it should be trying to use the custom Sailpoint synonym’s that we created (SP\_FND\_USER\_PKG).

Also for reference, here is the database account that we’ve been using to provision users: SRVC\_SPOINT. This is the user that exists in the **dba\_users** table in our Oracle Database (different than the EBS user above).

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/b/a/bac6d41eda186611b7782b430d16b54c4fbc3660.png)

Wondering if this is a bug, thanks!

---

<div class="post-metadata">

**Author:** ![raeannehinkens](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@raeannehinkens](https://developer.sailpoint.com/discuss/u/raeannehinkens)\
**Post date:** [March 13, 2026, 1:53pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/3 "2026-03-13T13:53:41Z")

</div>

Hello, after further testing, it appears that the documentation could be incorrect or should be updated in the grants section for **INVOKER** vs **DEFINER** rights. We have to use **INVOKER** rights based on our EBS configuration using R12.2.12. Every error we get when trying to use the **Audit User Name** to replace the ANONYMOUS user in LAST\_UPDATED\_BY the FND\_USER table during provisioning comes from the database account trying to use Seeded permissions instead of Custom permissions.

The Required Permissions document [https://documentation.sailpoint.com/connectors/oracle/ebusiness\_suite/help/integrating\_oracle\_ebs/required\_permissions.html](https://documentation.sailpoint.com/connectors/oracle/ebusiness_suite/help/integrating_oracle_ebs/required_permissions.html) has us check permissions here:

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/8/e/8ed1b39b0ea7a6c0286850f8b5900b75d316b65a.png)

And our Permissions in the database are INVOKER, so we had to create synonyms for the seeded packages created by **SRVC\_SPOINT** user.

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/e/6/e6597b2192a9688dacb7400dc10e0583a97fd0ff.png)

_ **Here is our DDL for the SRVC\_SPOINT database user:** _

CREATE USER “SRVC\_SPOINT” IDENTIFIED BY “PASSWORD” TEMPORARY TABLESPACE “TEMP”;

ALTER USER “SRVC\_SPOINT” ENABLE EDITIONS FOR VIEW, SYNONYM, PROCEDURE, FUNCTION, PACKAGE,TRIGGER, TYPE, LIBRARY;

GRANT CREATE SESSION TO “SRVC\_SPOINT”;

GRANT SELECT ANY TABLE TO “SRVC\_SPOINT”;

GRANT CREATE SYNONYM TO “SRVC\_SPOINT”;

GRANT CREATE PUBLIC SYNONYM TO “SRVC\_SPOINT”;

GRANT SELECT ON “SYS”.“DUAL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “SYS”.“DBA\_USERS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “AR”.“HZ\_PARTIES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “AR”.“HZ\_CUST\_ACCOUNTS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_ROLES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_ROLES\_TL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_RESPONSIBILITY\_TL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_RESPONSIBILITY” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION\_TL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “SYS”.“DBA\_USERS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_ALL\_PEOPLE\_F” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_PERIODS\_OF\_SERVICE” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_PERIODS\_OF\_PLACEMENT” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_ALL\_PEOPLE\_F#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_PERIODS\_OF\_PLACEMENT#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “HR”.“PER\_PERIODS\_OF\_SERVICE#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_PRODUCT\_GROUPS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_DATA\_GROUPS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_DATA\_GROUP\_UNITS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_USER” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_ROLES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_USER\_ROLES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_ROLE\_HIERARCHIES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_RESPONSIBILITY” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_REQUEST\_GROUP\_UNITS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_REQUEST\_GROUPS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_MENU\_ENTRIES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_MENUS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION\_TL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_FORM\_FUNCTIONS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_APPLICATION\_TL#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_DATA\_GROUPS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_DATA\_GROUP\_UNITS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_FORM\_FUNCTIONS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_MENUS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_MENU\_ENTRIES#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_PRODUCT\_GROUPS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_REQUEST\_GROUPS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_REQUEST\_GROUP\_UNITS#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_RESPONSIBILITY#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“FND\_USER#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_ROLES#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_LOCAL\_USER\_ROLES#” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPLSYS”.“WF\_ROLE\_HIERARCHIES#” TO “SRVC\_SPOINT”;

**GRANT EXECUTE ON “APPS”.“SP\_FND\_GLOBAL” TO “SRVC\_SPOINT”; --this is the grant that it should be using, not APPS.FND\_GLOBAL**

GRANT EXECUTE ON “APPS”.“SP\_FND\_RESPONSIBILITY\_PKG” TO “SRVC\_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP\_FND\_USER\_PKG” TO “SRVC\_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP\_FND\_USER\_RESP\_GROUPS\_API” TO “SRVC\_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP\_FND\_WEB\_SEC” TO “SRVC\_SPOINT”;

GRANT EXECUTE ON “APPS”.“SP\_WF\_LOCAL\_SYNCH” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“AR\_CUSTOMERS” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_APPLICATION\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_FORM\_FUNCTIONS\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_MENUS\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_MENU\_ENTRIES\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_RESPONSIBILITY\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_USER\_RESP\_GROUPS\_ALL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“FND\_USER\_RESP\_GROUPS\_DIRECT” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“WF\_ALL\_ROLES\_VL” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“WF\_ROLES” TO “SRVC\_SPOINT”;

GRANT SELECT ON “APPS”.“WF\_USER\_ROLES” TO “SRVC\_SPOINT”;

We get the following error when logged in as SRVC\_SPOINT user in SQL Developer when trying to run the test PL/SQL given, since the documentation says to use the SP\_FND\_GLOBAL synonym:

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/f/9/f94ecb9fca5df112bc88c32143bbe01eed4ec71d.png)

USER is “SRVC\_SPOINT”

FND\_GLOBAL.APPS\_INITIALIZE(

\*

ERROR at line 2:

ORA-06550: line 2, column 3:

PLS-00904: insufficient privilege to access object APPS.FND\_GLOBAL

ORA-06550: line 2, column 3:

PL/SQL: Statement ignored

[https://docs.oracle.com/error-help/db/ora-06550/](https://docs.oracle.com/error-help/db/ora-06550/)

More Details :

[https://docs.oracle.com/error-help/db/ora-06550/](https://docs.oracle.com/error-help/db/ora-06550/)

[https://docs.oracle.com/error-help/db/pls-00904/](https://docs.oracle.com/error-help/db/pls-00904/)

For reference, here is the EBS user (fnd\_user) that we created and also granted **System Administrator** to (which would not be allowed per auditing in our PROD EBS environment): [https://documentation.sailpoint.com/connectors/oracle/ebusiness\_suite/help/integrating\_oracle\_ebs/additional\_settings.html](https://documentation.sailpoint.com/connectors/oracle/ebusiness_suite/help/integrating_oracle_ebs/additional_settings.html)

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/7/e/7e18629b4824f1c7da48bccc9449866e11185d1c.png)

Can someone please confirm if using the **Audit User Name** option in **Sailpoint** works with **INVOKER** rights in Oracle EBS R12.2.12 and Oracle DB 19c?

Thanks!

---

<div class="post-metadata">

**Author:** ![raeannehinkens](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@raeannehinkens](https://developer.sailpoint.com/discuss/u/raeannehinkens)\
**Post date:** [March 24, 2026, 5:45pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/4 "2026-03-24T17:45:44Z")

</div>

anyone else had thoughts on this? support seems to think it’s permissions, but everything exactly lines up with the INVOKER permissions on the document linked above. thanks!

---

<div class="post-metadata">

**Author:** ![raeannehinkens](https://avatars.discourse-cdn.com/v4/letter/r/6de8d8/32.png) [@raeannehinkens](https://developer.sailpoint.com/discuss/u/raeannehinkens)\
**Post date:** [April 10, 2026, 2:41pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/5 "2026-04-10T14:41:36Z")

</div>

still no luck on this, not sure if anyone has successfully gotten this to work

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [June 9, 2026, 2:42pm UTC](https://developer.sailpoint.com/discuss/t/oracle-e-business-setting-disableinitializesession-false-causing-errors/198988/6 "2026-06-09T14:42:30Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.