In Oracle Cloud ERP, or any other ERP application, you have “seeded roles.” Seeded roles are the preconfigured roles delivered with your application, and they are designed to get you up and running. Seeded roles are widely used during application implementation to get you live quickly. These seeded roles include application implementation consultant, IT security manager, accounts payable manager, and accounts receivable manager. These roles are generic and represent many of your organization’s tasks. You can use these roles out of the box on day one to get started. However, these roles should not be used and relied upon indefinitely.

To understand role customization, let’s look at how roles are structured.

At the top level is the abstract role. An abstract role relates to a person’s purpose in the organization above their job—for example, employee. As an employee, you can enter expenses, timekeeping, request time off, etc. These are the tasks you perform regardless of what job you’re employed to do. 

The next level is the job role. The job role should reflect the job the person performs. And within that, there are duty roles. Duty roles contain the individual tasks a person performs as part of their job. For example, a sales manager may have a sales manager job role. And with the sales manager duty role, the user can enter sales orders, and with an additional duty role, they can approve sales orders. 

At the bottom of the role structure is privilege. A privilege is the lowest level of security, granting users access to the pages in the application where they can enter and update transactions. 

Release management and seeded roles

Oracle and most cloud applications roll out new releases quarterly. And when the update is released, it will go to your development test environment and eventually to production. However, you need to be aware when using seeded roles the new functionality or the removal of functionality impacts the seeded roles in your environment with every update.  

New functionality and privileges assigned to the seeded roles means that when this update hits production, your users will get that new functionality. If you don’t review these changes and their impact, your users will get that new functionality when it moves to production. Not reviewing these changes quarterly, risks users being granted functionality they should not have.

You should review roles that can create, maintain or approve transactions and change the application’s configuration. Users who can change how the systems are configured can change how processes are configured and assign themselves to join those transactions. 

Segregation of duty conflicts are also inherent in seeded roles. Many of the seeded roles can create and approve various transactions. Additionally, numerous roles contain sensitive access risks allowing access to sensitive data areas. You will need to review these seeded roles to ensure they comply with various pieces of legislation. And seeded role review is a quarterly process following the roll-out of vendor updates. 

Currently, the most acute risk in an Oracle-seeded role is the abstract role of the Employee. As is, this role allows users to create an FDBI file, upload it, and run the process to create a new bank account where the user can input their banking information for future payments. Similar capabilities are also available in Workday, NetSuite, or any other SaaS provider to provide System Integrators and management the ability to convert data. This is not unique to ERP Cloud.

The importance of customized role design 

The #1 reason for audit findings is poorly designed roles stemming from “seeded roles” (see chart above). A role management solution like SafePaaS Roles Manager allows process owners to design and simulate secure roles to increase security configurations for your Oracle ERP Cloud implementation. 

Many organizations face challenges when granting roles and access to applications. A best practice when customizing roles is to ensure that the user’s requirements for access fit their role and your information security policies. 

When users are granted access to transactions, master data, and system configurations, it can result in higher IT maintenance and audit costs due to the associated costs of correcting those privileges. Having a solution that can simulate roles before they go into your ERP can:

• Improve access policy compliance 

• Reduce implementation and upgrade costs by testing roles to ensure they are conflict-free 

• Lower total cost of ownership by controlling changes to roles

• Avoid segregation of duties conflicts with effective role design

• Address user security without creating access violations

• Automate role design and simulate security before violations get introduced into your system

• Uncover privileges by scanning access to applications using the security structure of your business application

• Improve application security and user productivity with effective role design

We recommend moving away from seeded roles and customizing your roles. Aside from reducing risk, the added benefit is that they won’t automatically get updated. You’re in control of those roles and what they can do. 

Whether you customize your roles pre-go live or post-go live, you must review your role structure to comply with regulations like Sarbanes Oxley and GDPR. And many seeded roles introduce risks that won’t get you past the mark when it comes to audit.