You’re running into two different but related behaviors in ODC:

1. How fast user/role changes become visible in the platform APIs
2. How and when those changes are actually used by the running application / session

From what you describe, both “activation” and “group assignment” are eventually consistent in ODC and can take some minutes to propagate. This aligns with what’s known from the classic platform and with current ODC limitations regarding user management APIs. Secure your app with end-user roles

Below is how this typically works and what you can do.

1. Expected behavior: propagation & session caching

a. Roles/groups are not recalculated in an active session

On the classic platform, when you change end‑user roles or group membership via API, those changes are not applied to an already logged‑in user; roles are calculated on login and cached for the session. The user needs to log out and log back in for the new permissions to be used. Secure your app with end-user roles

ODC is a new product, but current documentation and community feedback indicate very similar behavior:

• Role/group changes are stored centrally.
• There is internal propagation / caching.
• An existing session may continue using old permissions until a new login.

This explains why your “grant permissions → immediately launch app” flow sometimes fails:
the launch is happening before ODC has finished updating the effective permissions for that user and/or before a fresh session uses them.

b. Activation via API is also eventually consistent

For activation/inactivation, ODC currently does not expose direct APIs in app logic; they exist at platform level (portal / internal APIs) and are not fully documented yet. Community feedback indicates:

• Activation/inactivation can be done via User and Access Management API.
• These changes are not instantaneous from the app’s point of view.
• There is a delay (seconds to minutes) until the new “Active” state is honored for login/authorization. Secure your app with end-user roles

So the behavior you are seeing (a delay of several minutes) is consistent with what others have reported and should be considered expected for now.

2. Patterns and workarounds for your scenario

Your requirement:

1. Check custom authorization table.
2. If allowed:
   • Activate user (Inactive → Active).
   • Add user to required End‑User Group(s).
3. Immediately launch target app.

To make this robust, you’ll need to separate “grant permissions” from “launch app” and introduce checks or delays.

Pattern A – “Provision then login” flow

1. Provision Phase (admin flow / API flow):

   • Activate the user via User & Access Management API.
   • Assign the user to the required End‑User Groups.
   • Do not immediately redirect to the app.

2. Wait / Verify Phase:

   • Poll the API until:
     • User.Active = True in the platform.
     • Membership in the required End‑User Group(s) is visible via the API.
   • Only when both are confirmed, present the user with a “Start Application” button or redirect.

3. Login Phase (new session):

   • Let the user authenticate after provisioning is stable.
   • The new session will calculate and cache the correct roles.

This avoids launching the app while permissions are still propagating.

Pattern B – Force “fresh session” after changes

If provisioning is triggered by a logged‑in user:

1. Perform activation and group assignment.
2. Show a message like:
   • “Your access was updated. Please sign in again to use the new application.”
3. Force logout (clear session) and redirect to login for the target app.

Because roles are calculated at login, this ensures the new roles are effective.
This is the same recommendation as on the classic platform. User Roles Updated via API Not Reflected During Active Session

Pattern C – Async provisioning plus notification

For a smoother UX:

• Trigger a background provisioning process (server action / timer / external orchestrator) that:
  • Activates the user and assigns the groups.
  • Logs completion in your custom table (e.g., ProvisioningStatus = “Ready”).
• The target app checks this status on startup:
  • If ProvisioningStatus != "Ready", show a “Preparing your access…” page and retry (with polling + timeout) before letting the user enter.
• Optionally, send an email or in‑app notification when access is fully ready.

This makes the propagation delay explicit and controlled.

3. Is the delay “normal” in ODC?

Based on current documentation and forum discussions:

• ODC user/role APIs are still evolving; some functionality (like activation/inactivation from app logic) is not fully exposed or documented yet. How to make users inactive in logic flow ODC
• Role/permission evaluation is designed to be secure and consistent, not necessarily instantaneous.
• For existing sessions, updated roles are not automatically reevaluated; a new login is required.
• Propagation delay of several minutes for changes to be usable is something practitioners have reported and is, at this moment, expected behavior rather than a misconfiguration.

So for your question:

• Is this expected behavior in ODC?
  Yes, current behavior (delay + need for a new session) should be treated as expected.

• Any pattern to handle “grant then immediately launch”?
  Use one of the patterns above:

  • Provision first, then login.
  • Or force logout and re‑login after permission changes.
  • Or implement async provisioning + readiness checks before entering the app.

4. Practical recommendations for your implementation

Given your custom authorization table and the need to launch the app right after granting permissions:

1. Do not rely on immediate consistency.

   • Always assume user activation and group membership may take some time.

2. Add a readiness check before launching the target app:

   • After calling the User & Access Management API:
     • Poll user status and group membership.
     • Only proceed when they match the required configuration.
   • Add a maximum timeout and an error message if provisioning is taking too long.

3. Prefer “login after provisioning” rather than “provision during active session”:

   • If possible, perform all changes while the user is not logged in.
   • Then ask them to authenticate into the target app as a separate step.

4. Document this behavior for operations/users:

   • Communicate to stakeholders that permission changes are not instant and may require re‑login or a short wait.

If you share a bit more about how you’re launching the target application (e.g., link from another app, SSO portal, external link), I can suggest a more concrete flow tailored to that entry point while still respecting ODC’s current limitations.