User role provisioning delays prevent access to UDOs in real estate management

ERP Oracle JD Edwards
, , , , , , , ,
1

We’re experiencing significant delays in user access provisioning for our real estate management module. New users are assigned roles that include UDO permissions, but they can’t access the UDOs for 24-48 hours after role assignment.

The role assignment shows as complete in User Profile (P0092), and the security roles include explicit UDO mappings for our custom real estate objects (property valuations, lease agreements, tenant records). However, when users try to access these UDOs through forms or reports, they get ‘insufficient permissions’ errors.

After waiting 1-2 days, access suddenly works without any additional changes. This delay is causing major onboarding issues - new property managers can’t do their jobs for days after being hired. The standard JDE tables and applications work immediately, only UDO access is delayed. Is there a security cache that needs manual refresh for UDO permissions?

2

You can submit R98403 via AIS REST API using the batch job submission endpoint. After your HR system assigns roles through P0092 APIs, add a second API call to submit R98403 with UDO cache clear option. The UBE runs asynchronously, so you’ll need to poll job status, but typical execution is under 2 minutes.

Alternatively, use Orchestrator to chain the operations - role assignment followed by cache clear. This gives you better error handling and retry logic if the cache clear fails.

3

Thanks, I ran R98403 with UDO cache clear option after assigning roles to two new property managers. They were able to access UDOs within 15 minutes. However, running this system-wide cache clear for every new hire seems excessive. Is there a way to refresh cache for specific users instead of all users?

4

UDO security uses a separate cache from standard object security. When you assign roles with UDO permissions, the changes don’t propagate immediately to the UDO security cache. The 24-48 hour delay you’re seeing is likely the default cache refresh interval.

You can force immediate refresh by running R98403 (Clear Security Cache) with option to clear UDO cache specifically. However, this affects all users system-wide, so coordinate with your team before running.

5

Here’s a comprehensive solution for eliminating UDO access delays during user provisioning:

Understanding the Problem:

JDE maintains separate security caches for standard objects and UDOs. When you assign a role containing UDO permissions:

  1. Standard object permissions (tables, forms, reports) activate immediately
  2. UDO security mappings are written to database (F98UDOSEC, F98UDORL)
  3. UDO security cache refreshes on a scheduled interval (default 24 hours)
  4. Users can’t access UDOs until cache refresh pulls their new permissions

This architecture causes the 24-48 hour delay you’re experiencing.

Solution Strategy: Three-Tier Approach

Tier 1: Optimize UDO Security Mapping (Immediate)

Verify your role’s UDO security is correctly configured:

  • Navigate to Security Workbench (P98OWSEC)
  • Open the real estate role assigned to new users
  • Check UDO Security tab - ensure UDOs are mapped with explicit permissions (Read, Write, Delete)
  • Verify role assignment propagation is set to ‘Immediate’ not ‘Batch’

Many delays stem from roles that reference UDO security groups instead of direct UDO mappings. Direct mappings propagate faster.

Tier 2: Automate Security Cache Refresh (Recommended)

Integrate cache refresh into your provisioning workflow. Since your HR system uses JDE APIs, add this sequence:

Step 1 - Role Assignment (existing):

POST to /jderest/v2/dataservice/table/F0092 (User Profile)

Step 2 - Submit Cache Clear (new):

POST to /jderest/v2/orchestrator/batch_job_submit

Payload:


{
  "jobName": "R98403",
  "version": "ZJDE0001",
  "processingOptions": {
    "CacheToClear": "UDO",
    "Scope": "AllUsers"
  }
}

Step 3 - Poll Job Status:

GET /jderest/v2/orchestrator/batch_job_status/{jobId}

Wait for status = “D” (Done), typically 60-120 seconds

Step 4 - Verify Access:

Have your HR system trigger a test API call to a real estate UDO endpoint to confirm the new user can access it

Tier 3: Configure Proactive Cache Refresh (Long-term)

Reduce the default cache refresh interval to handle edge cases where automated refresh fails:

Edit jde.ini on all enterprise servers:


[SECURITY]
UDOSecurityCacheRefresh=7200
UDOCacheRefreshMaxThreads=4
UDOCacheRefreshTimeout=300

This sets 2-hour automatic refresh (down from 24 hours). Even if API-triggered refresh fails, users wait maximum 2 hours instead of 24-48 hours.

Performance Considerations:

  • 2-hour refresh interval adds ~0.5% CPU overhead on enterprise servers
  • R98403 execution takes 1-2 minutes and locks security tables briefly
  • Running R98403 per user (10-15/month) has negligible impact
  • System-wide cache clear affects all active users (they might need to re-login)

Alternative: User-Specific Cache Refresh

If system-wide cache clear is problematic, implement a custom solution:

  • Create a custom UBE that clears security cache only for specified user IDs
  • Use SQL to delete from F98UDOCACHE WHERE USER_ID = :newUserId
  • Call this custom UBE via API instead of R98403
  • Users get immediate access without affecting other users’ cached permissions

This requires custom development but provides surgical cache refresh.

Implementation Checklist:

  1. Verify UDO security mappings are direct (not group-based)
  2. Update HR provisioning workflow to call R98403 via API after role assignment
  3. Implement job status polling with 5-minute timeout
  4. Reduce UDOSecurityCacheRefresh to 7200 seconds in jde.ini
  5. Test with new hire - verify UDO access within 5 minutes of role assignment
  6. Monitor R98403 execution times and adjust if needed
  7. Document the automated workflow for IT team

Expected Results:

  • New users get UDO access within 2-5 minutes after role assignment
  • No manual intervention required
  • Fallback 2-hour cache refresh handles any automation failures
  • Property managers can start work immediately upon hire

This solution eliminates the 24-48 hour delay while maintaining security cache integrity and system performance.

6

Be careful with aggressive cache refresh intervals. UDO security queries can be expensive if you have complex role hierarchies or large numbers of UDOs. I’ve seen environments with 1-hour refresh intervals experience performance degradation during peak usage.

A better approach might be automating R98403 execution as part of your user provisioning workflow. Trigger it programmatically after role assignment completes, targeting just UDO cache refresh. This gives you immediate access without impacting system-wide cache refresh scheduling.

7

User-specific cache refresh isn’t available in standard JDE. However, you can adjust the UDO security cache refresh interval in your enterprise server configuration. Check jde.ini for UDOSecurityCacheRefresh setting. Default is usually 86400 seconds (24 hours).

Reducing this to 3600 seconds (1 hour) would make role changes effective much faster without requiring manual cache clears. The tradeoff is slightly higher database load from more frequent cache refreshes, but with real estate management UDO volume, impact should be minimal.