Oracle Fusion Applications — Why are roles so important?
Before I get into the complexities of Oracle licensing (even though Oracle Fusion Applications is a subscription!) and roles and responsibilities, I will give you a brief summary of what Oracle Fusion Applications is, how it’s used and what for.
What are Oracle Fusion Applications?
Oracle Fusion Applications are one of Oracle’s cloud offerings, where applications are available to customers via a browser on demand. So, in effect, any authorised user can access the applications (with the right security and access) from literally anywhere in the world. That alone is a very good selling point, but when you couple that with added security, controls and application features, it makes for one of the most functional pieces of cloud subscription ERP software in the world.
Oracle Fusion Applications is available with the following deployment options:
· Public cloud (available to the general public), hosted over the Internet by Oracle, software as a service (SaaS), or Oracle business partners offering business process outsourcing.
· On premises, hosted by the customer.
· There are many different modules to Oracle Fusion Applications, such as Financials (ERP), Projects, Customer Relationship Management (CRM), Human Capital Management (HCM), Supply Chain Management (SCM) and Procurement to name a few of the most widely used core modules.
However, having a subscription to Financials ERP does not mean you can use responsibilities available in Procurement or Projects, for example.
Learn more about Version 1 x Oracle an award-winning collaboration.
Seeded or Custom Roles?
What is a seeded role? A seeded role is a preconfigured ‘out-of-the-box’ role that is designed to help you get started on the system — to ‘speed’ up the implementation stage by using a default role that gives you access to the most commonly used modules, for ease and speed of deployment.
Roles such as Employee Role, Application Implementation or anything with ‘ORA’ prefix, for example, would be seeded roles. By default, seeded roles grant access to a lot of different modules (ones likely not in your subscription).
These seeded roles get updated by Oracle on a quarterly basis and as such, could have features (responsibilities) removed or added to the role during these updates — what does that mean to you? Well, if you are not paying attention to the seeded roles and their impact then an unexpected usage could be highlighted in the SaaS Service Usage Metrics Report.
This is where we see a lot of customers getting into trouble. Commonly, I find customers unwittingly ‘create’ issues at the implementation stage, where seeded roles are used for speed to deployment, i.e. new users are created, and these users are assigned in the system to a seeded role with considerably more responsibilities than necessary.
Only once the system goes live and is in ‘real world’ use would Oracle start to notice unexpected usage on the ‘Oracle SaaS Service Usage Metrics Report’. Be aware that not only can you download and read this report, so can Oracle. Reading the SaaS Services Usage Metrics Report is relatively easy, but what it shows could be alarming, especially if all users have been granted access to (or given extra responsibilities for) modules that ultimately you have not bought enough subscriptions for.
So, now that we know seeded roles should not be used, what should you use? In my experience, you should make copies of the seeded roles, as custom roles — but remove responsibilities that your users do not need. You can choose whether to do this pre-go-live / testing stage or after go-live — but this step must be done to prevent falling foul of unexpected usage.
If you look at the seeded role Application Implementation, you will see that there are several SKUs associated to the role — refer to table 1.
Table 1 shows all SKUs that are associated to the prefixed ‘ORA’ application implementation role. This role has an impact on your subscriptions — if there are any users active and, in this role, they would be counted as ‘authorised’ to use the service and therefore, in using Oracle’s Hosted Named User definition, you would be liable to have a subscription.
So, when you transpose this theory to an Employee seeded role, with thousands of users, you can quickly see what the costs would be. For example, if you have unexpected usage of B91079 (Oracle Fusion Enterprise Resource Planning Cloud Service — Hosted Named User), the base cost of this subscription alone is $625 per user per month! So, for even 100 ‘extra’ users, you would be looking at a bill of $750k (list price) extra per annum!! And that would just be for Financials. Imagine what the costs would be for multiple modules …
Custom Roles and how to set them up
Oracle Fusion SaaS by default will set up and create seeded roles, for ease of use and speed to deploy, but this can create issues for you if you have not bought all the subscriptions that these seeded roles could potentially use. Therefore, it is better to create custom roles, and only add privileges that are required for the job profile — using the principle of least privilege. This way it not only reduces the issues of being under subscribed but also creates job segregation — where for example a purchaser is not an approver, as they are separate roles with separate privileges. A further benefit of a custom role is that they will not auto update like seeded roles will do — therefore your custom role will not add in any unexpected privileges during the deployment.
In my experience, it is much quicker to copy a seeded role and then remove privileges not required rather than create a new role from a blank canvas.
Steps to copy a role are as follows:
1. In the security console, search for the Role you want to copy, for example ‘Procurement Manager’.
2. From the dropdown menu select Copy Role.
3. Give the Role a new name.
4. The security console will display all privileges in the new role with descriptions, from which you can remove if not required.
However, if you prefer to start from scratch, you can create a brand-new role and assign privileges and users to it. Follow the guide below for creating a brand-new role.
How to create a new role:
1. Select the Security Console from the menu and once loaded, select Roles.
2. Click Create Role in the upper right-hand corner of the console.
3. Fill in the necessary information:
a. Name and Code: provide a descriptive name for the custom role — something that is easily identified in name.
4. Role Category: select the functional area for the role like Procurement — Job Roles.
5. Description: optional, add a brief description.
6. Click Next.
7. Use the Function Security Policies area to now assign your privileges to your role. Do this by clicking Add Function Security Policy and a window will appear to search and add your privileges.
8. Once the privileges are added, you should select which users to add to the role. This can be edited later i.e. you can add or remove users from a role subsequently as needs arise.
9. Click Save and Close, and that is your role created.
In summary
So why are Roles so important? They are the best way of preventing your business from having ‘Unexpected Usage’ in your Oracle Fusion SaaS subscription. When you create a custom role, you should only assign privileges that are within your subscription, and therefore any unwanted or unexpected usage should not appear, or if they do, they can be easily remediated by user and role administration.
A problem with using seeded (default) roles is that Oracle updates them on a regular basis — so possibly a role is okay for one year, but by the next year, it may have had additional privileges added to it, meaning it could be consuming a different subscription that you have not bought on your cloud subscription.
When you use custom roles, Oracle does not update these — so by using custom roles, this immediately removes the danger.
So, why does Oracle provide seeded roles, you may ask? The reason is that it makes adoption quicker, installation easier and it is the default for everyone worldwide — they cannot provide custom installations for every user in the world — the responsibility is yours to ensure user privileges equals subscription.
As ever with Oracle, it is incumbent on you to fulfil licensing requirements and not on Oracle to monitor your usage. But be aware that Oracle can see your usage and, in our experience, will assess your usage and if found to be on the wrong side of compliance, will call this out at or before renewal periods.
So, if you want to ensure that you are in line with compliance and understand the importance of custom roles, reach out to us at Version 1. We have a long history of Oracle Fusion SaaS implementations and can easily identify what users/roles you have installed and can evaluate your compliance.
If you have any questions on how to implement custom roles in Oracle Fusion SaaS or require advice and guidance around your existing methodologies, go to our website or contact us to get some valuable information and advice.
About the Author:
Johnny Cree is a Principal License consultant at Version 1.
