2Access Models

This chapter contains the following:

An access model defines risk in the assignment of access points, which are roles or privileges that enable users to work with data in business applications. The model may identify access points that conflict, because in combination they would allow individual users to complete transactions that may expose a company to risk. Or it may identify a single access point that presents inherent danger, typically because it provides broad access.

An access model consists of filters that specify access points or that select records for analysis. Each filter cites a business object, which supplies data for analysis.

Access Point and Entitlement Filters

A filter may specify an access point or an entitlement, which is a set of related access points. The filter selects users assigned either the specified access point or any point in the specified entitlement. A model must contain at least one, and typically contains two or more, of these filters. It returns records of users selected either by a single filter or by defined combinations of multiple filters.

Condition Filters

A filter may define a condition, which grants exemptions from access analysis. A model begins with a set of records involving access points specified by access-point and entitlement filters. Condition filters select records from that set, and so exclude the records they don't select. Such a filter may specify items, such as users or business units, to be included in analysis. Or it may require the model to consider access granted only within, or only across, individual instances of items such as business units.

Note: Before you can create or run access models, you must synchronize global users at least once. This procedure assigns an ID to each person who uses business applications subject to models and controls created in Advanced Controls. That ID correlates to potentially varying IDs the person may have for business-application accounts.

Create or Edit an Access Model

As you create or edit an access model, you select business objects, which provide data from your Oracle Cloud instance for the model to evaluate. You then define filters that select risky records from that data.

You can also select perspective values for the model. These may serve as filtering values in the Models management page. If you create a model, you're automatically its owner, but you can add other users to the model as owners, editors, or viewers only after you save the model for the first time.

To work with access models, select Risk Management in the home page. Among its options, select Advanced Controls. Then select a Models tab; it opens a Models management page that lists the models you have access to.

  • To create a model, select Actions > Create Access Model in the Models management page. This opens a Create Access Model page. Begin by naming and describing the model.

  • To edit a model, select its row in the Models management page, then select Edit. As an alternative, click the model name to open a read-only page that provides details of the model's configuration. In that page, click the Edit button. Either action opens an Edit page, a replica of the Create page populated by values for the model you want to edit.

As you create an access model, select one or more business objects for it:

  • Select the Access Point business object to create a filter that specifies an access point, and returns users assigned that access point.

  • Select the Access Entitlement business object to create a filter that specifies an entitlement, and returns users assigned any access point in that entitlement.

  • Select the Access Condition business object to create a condition filter, which defines exemptions from analysis by a model.

Make Selections

To add objects to a model:

  1. Click Add in the Model Objects section of the page to create or edit a model. A Select Business Objects page opens.

  2. Select the objects you want. For each, click the plus sign in its row. Note that the plus-sign icon changes when you click it.

  3. When you finish selecting objects, click Back to return to the create- or edit-model page. (Back is represented by an icon that looks like a less-than symbol.) A representation of each object appears in the Model Objects section. In it, you can view the attributes of the object.

Modify Selections

Once you have selected objects for a model, you can remove them in either of two ways:

  • Open the Select Business Objects page, click on the icon for an object you have selected, and it becomes a plus sign once again. When you finish modifying selections, click Back.

  • Use the representation of an object in the Model Objects section of the create- or edit-model page. There, click the x icon in the title bar of the object.

A filter may specify an access point, and return users who have been assigned that access point. Or a filter may specify an entitlement, and return users who have been assigned any access point included in that entitlement.

To create either type of filter:

  1. In the Model Logic section, click Add Filter. A dialog box appears. Enter a name for the filter in its Name field.

  2. An Object field lists the business objects you have added to the model in the Model Objects section. Select Access Point for an access-point filter, or Access Entitlement for an entitlement filter.

  3. Accept default values in three fields:

    • In an Attribute field, accept Access Point Name for an access-point filter or Access Entitlement Name for an entitlement filter.

    • In a Condition field, accept Equals for either filter type.

    • In a Type field, accept Value for either filter type.

  4. In a Values field, click Search. A search dialog opens. In it, search for and select an access point or an entitlement. Among search criteria:

    • Name and Description are display values identifying an access point or entitlement.

    • Access Point ID applies only to access-point filters. It's the internal name for a role or privilege, or the path to a user-defined access point.

    • Type applies only to access-point filters. Select Privilege, Role, or User Defined to return access points of the type you select.

    • As you enter search values you can use the percent symbol (%) as a wildcard.

A filter may select records in which the values of an attribute satisfy a condition. A model may contain any number of these condition filters. The access-point and entitlement filters in a model define a pool of records subject to access analysis: all records involving the access points they specify. Condition filters reduce this pool, selecting records from it and therefore excluding records they don't select.

For example:

  • A model may contain a single condition filter that states, "Business Unit equals Consumer Electronics." By selecting records involving a business unit called Consumer Electronics, it excludes all other units from analysis.

  • Conversely, the filter might state, "Business Unit does not equal Consumer Electronics." It selects records involving all other business units, and so excludes the Consumer Electronics unit from analysis.

Condition filters have an OR relationship to one another. Each operates independently, so items that seem to be excluded by one can be selected by others. For example, the condition filter "Business Unit equals Consumer Electronics" would, by itself, exclude all other units, among them one called Database Servers. But if you were to create a second condition filter, "Business Unit equals Database Servers," the model would evaluate records involving both the Consumer Electronics and Database Servers units.

A second type of condition filter uses a "Within Same" attribute to select records of access assignments only within, or only across, entities such as business units. It too would exclude the records it doesn't select from analysis by its model. For example:

  • A filter may state, "Within Same Business Unit equals Yes." It would select records of access assignments solely within individual business units. It would exclude records of access granted across units: one conflicting access point granted in, say, the Database Servers unit and a second granted in the Consumer Electronics unit.

  • Conversely, the filter may state "Within Same Business Unit equals No." It would select records of access granted across business units, but not access granted solely within individual units.

Note: Within Same conditions are for use in models that evaluate access risk in applications other than Human Capital Management. Don't use Within Same conditions in filters for Human Capital Management access models.

Although every access model must include at least one access-point or entitlement filter, condition filters are optional.

To create a filter that defines an access condition:

  1. In the Model Logic section, click Add Filter. A dialog box appears. Enter a name for the filter in its Name field.

  2. An Object field lists the business objects you have added to the model in the Model Objects section. Select the Access Condition object.

  3. In the Attribute field, select the attribute you want to base the condition on. To create a filter that selects records and implicitly excludes others, select an attribute that names the type of entity to be included or excluded. To create a filter that directs a model to look within or across entities, select a "Within Same" attribute.

  4. In the Condition field, select one in a set of predefined conditions. These are described below.

  5. In the Type field, accept the default selection, Value. In a Value field, select or enter values that complete the condition you selected.

The only condition available to a "Within Same" attribute is Equals, and the only values you can select for it are Yes and No. For other attributes, you can select these conditions:

  • Equals or Does not equal: Consider only records in which the attribute value does, or doesn't, match a value you select in the Value field. For example (as described above), "Business Unit equals Consumer Electronics" selects the Consumer Electronics unit for analysis, and so excludes other units.

    If a filter uses the Access Point attribute with either the Equals or Does not equal condition, it returns or excludes records in which a specified access point exists anywhere in a path. For example, suppose the Calculate Gross Earnings privilege exists in two role hierarchies, "Payroll Manager > Calculate Gross Earnings" and "Payroll Interface Coordinator > Calculate Gross Earnings." The filter "Access Point does not equal Calculate Gross Earnings" would exclude both these role hierarchies from model analysis. (You can use path conditions to create more granular exclusions.)

  • Contains or Does not contain: Consider only records in which the attribute value includes, or doesn't include, a text string you enter in the Value field. For example, "User Name contains Super" selects a generic user called Payables Super User; an individual who uses her name, Juanita_Supera, as her user name; as well as other users whose names contain the string "Super." This condition excludes users whose names don't include "Super."

  • Matches any of or Matches none of: Consider only records in which the attribute value exactly matches one of any number of values you select in the Value field, or matches none of them. For example, "User Name matches none of BSMITH or TJONES" excludes those users from analysis by selecting all others.

Attributes of access conditions correspond to properties whose values are assigned to users in various places in Oracle Cloud applications. For example, if an access condition sets the Business Unit attribute equal to Database Servers, it selects records pertaining to a Database Servers unit defined in the Manage Data Access for Users task in Setup and Maintenance.

Navigation paths to the sources of these property values include:

  • Advanced Access Controls itself.

  • Others > Setup and Maintenance > search for and select Manage Data Access for Users. In this tool, the term for an attribute is "security context."

  • Tools > Security Console > Users.

Here are the sources of values that access conditions search for:

Access Condition Attribute Source

Access Entitlement Name

The Entitlements page in Advanced Access Controls. Values are the names of entitlements you have configured.

Access Point

The Security Console (where privileges and roles are sourced) and Advanced Access Controls (where user-defined access points are defined).

Asset Book

The Asset Book security context in Manage Data Access for Users

Business Unit

The Business Unit security context in Manage Data Access for Users

Data Access Set

The Data Access Set security context in Manage Data Access for Users

HCM Data Role

Role records in the Security Console

Ledger

The Ledger security context in Manage Data Access for Users

Reference Data Set

The Reference Data Set security context in Manage Data Access for Users

User Name

User records in the Security Console

You can create path condition filters. Each identifies one or more specific paths to access points. Such a condition filter may either exclude its specified paths from conflicts identified by a model, or include only those paths in conflicts.

To begin, create user-defined access points. Each is, in effect, a specific path to an access point. For example, one called "Payroll Manager > Calculate Gross Earnings" might provide access to the Calculate Gross Earnings privilege through a role called Payroll Manager.

Next, optionally, create an entitlement that includes user-defined access points you want to use in path conditions.

Finally, create a condition filter, either in an access model or a global condition. You may either:

  • Select the Access Point attribute of the Access Condition business object, and a single user-defined access point as its value.

  • Select the Access Entitlement Name attribute of the Access Condition business object. As its value, select an entitlement containing user-defined access points.

For either filter, you may:

  • Select the Does Not Equal condition. Paths specified by this condition filter are excluded from the results the model can return.

  • Select the Equals condition. Paths specified by this condition filter are included in the results the model can return; any other paths are excluded.

For example, assume that a model contains an access point filter that specifies the Calculate Gross Earnings privilege. The filter returns two results: Payroll Manager > Calculate Gross Earnings and Payroll Interface Coordinator > Calculate Gross Earnings.

  • The condition "Access Point Does Not Equal 'Payroll Manager > Calculate Gross Earnings'" would cause the model to return the path through the Payroll Interface Coordinator role.

  • The condition "Access Point Equals 'Payroll Manager > Calculate Gross Earnings'" would cause the model to return the path through the Payroll Manager role.

Exclusions Involving Procurement Agents

For certain privileges to grant functional access, a user must be granted both the privilege and a corresponding "action" as a "procurement agent" for a business unit. For example, suppose a user is assigned a role that includes the Create Purchase Agreement privilege. That user can actually create purchase agreements within a business unit only if he or she's also a procurement agent for that unit and is granted the Manage Purchase Agreements action. If not, then even though granted the Create Purchase Agreement privilege, that user can't create purchase agreements.

Note: Use the Manage Procurement Agents task in Cloud Setup and Maintenance to set up users as procurement agents and assign them actions.

Models created in Advanced Access Controls automatically exclude users who are granted any of these privileges but aren't also granted the corresponding procurement-agent action. This prevents the models from returning false-positive results. You don't need to create conditions to exclude these users.

A special consideration: Models don't take into account the business units in which procurement-agent assignments are granted. So if a model contains condition filters that involve business units, those filters may allow results that should be excluded. For example:

  • A user has the Create Purchase Agreement privilege. She also has the Manage Purchase Agreements procurement-agent action, but it applies only in a single business unit, BU1.

  • She also has a Create Payables Invoices privilege, but it's granted only within a second business unit, BU2.

  • A model includes access-point filters that place the two privileges in conflict, but also includes the condition filter "Within Same Business Unit Equals Yes."

  • The condition filter should cause the model to exclude the user, because her conflict doesn't occur within one business unit. Instead, the model returns a record of the user, because it ignores her grant of the Manage Purchase Agreements action being specific to BU1.

If an access-model filter cites any of the following privileges (or a role that includes it), the filter returns only users who are also assigned the corresponding procurement-agent action:

Functional Privilege Procurement-Agent Action

Acknowledge Purchase Agreement

PO_ACKNOWLEDGE_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Cancel Purchase Agreement

PO_CANCEL_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Change Purchase Agreement

PO_CHANGE_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Create Blanket Purchase Agreement Line from Catalog

PO_CREATE_BLANKET_PURCHASE_AGREEMENT_LINE_FROM_CATALOG_PRIV

Manage Purchase Agreements

Create Purchase Agreement

PO_CREATE_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Finally Close Purchase Agreement

PO_FINALLY_CLOSE_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Freeze Purchase Agreement

PO_FREEZE_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Hold Purchase Agreement

PO_HOLD_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Import Blanket Purchase Agreement

PO_IMPORT_BLANKET_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Import Contract Purchase Agreement

PO_IMPORT_CONTRACT_PURCHASE_AGREEMENT_PRIV

Manage Purchase Agreements

Transfer Blanket Purchase Agreement to Catalog Administrator

PO_TRANSFER_BLANKET_PURCHASE_AGREEMENT_TO_CATALOG_ADMINISTRATOR_PRIV

Manage Purchase Agreements

Transfer Blanket Purchase Agreement to Supplier

PO_TRANSFER_BLANKET_PURCHASE_AGREEMENT_TO_SUPPLIER_PRIV

Manage Purchase Agreements

Acknowledge Purchase Order

PO_ACKNOWLEDGE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Cancel Purchase Order

PO_CANCEL_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Cancel Purchase Order as Procurement Requester

PO_CANCEL_PURCHASE_ORDER_AS_PROCUREMENT_REQUESTER_PRIV

Manage Purchase Orders

Change Purchase Order Line Negotiated Indicator

PO_CHANGE_PURCHASE_ORDER_LINE_NEGOTIATED_FLAG_PRIV

Manage Purchase Orders

Change Purchase Order

PO_CHANGE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Change Supplier Site

PO_CHANGE_SUPPLIER_SITE_PRIV

Manage Purchase Orders

Close Purchase Order

PO_CLOSE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Create Purchase Order from Requisitions

PO_CREATE_PURCHASE_ORDER_FROM_REQUISITIONS_PRIV

Manage Purchase Orders

Create Purchase Order Line from Catalog

PO_CREATE_PURCHASE_ORDER_LINE_FROM_CATALOG_PRIV

Manage Purchase Orders

Create Purchase Order

PO_CREATE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Finally Close Purchase Order

PO_FINALLY_CLOSE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Freeze Purchase Order

PO_FREEZE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Hold Purchase Order

PO_HOLD_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Import Purchase Order

PO_IMPORT_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Purge Purchasing Document Open Interface

PO_PURGE_OPEN_INTERFACE_PRIV

Manage Purchase Orders

Reassign Purchasing Document

PO_REASSIGN_PURCHASING_DOCUMENT_PRIV_OBI

Manage Purchase Orders

Retroactively Price Purchase Order

PO_RETROACTIVELY_PRICE_PURCHASE_ORDER_PRIV

Manage Purchase Orders

Generate Purchase Order

PO_GENERATE_PURCHASE_ORDER_PRIV

Manage Purchase Orders and Manage Requisitions

Edit Supplier Profile Change Request

POZ_MAINTAIN_SUPPLIER_PROFILE_CHANGE_REQUEST_PRIV

Manage Suppliers

Edit Supplier Registration Request

POZ_EDIT_SUPPLIER_REGISTRATION_REQUEST_PRIV

Manage Suppliers

Maintain Supplier Site

POZ_MAINTAIN_SUPPLIER_SITES_PRIV

Manage Suppliers

Maintain Supplier

POZ_MAINTAIN_SUPPLIER_PRIV

Manage Suppliers

Position access-point filters and entitlement filters vertically or horizontally to each other to determine how they relate to one another as they're processed.

  • A vertical arrangement indicates an AND relationship: A conflict exists for users identified by filters at all levels.

    For example, an access model may contain three filters, one above another. The uppermost filter identifies users assigned one access point, the filter at the next level identifies users assigned a second access point, and the filter at the third level identifies users assigned a third access point. A conflict exists for each user assigned all three access points, and so identified by all three filters.

  • A horizontal arrangement indicates an OR relationship: Records are valid if returned by any filter or combination of filters in a horizontal set.

    For example, two filters alongside one another may be positioned above a third filter. Each filter specifies its own access point. A conflict would exist for each user assigned either the first and third access points, or the second and third access points.

A model can include access-point filters, entitlement filters, or both. There's no limit to the number of access-point filters, but for performance reasons, you can't include more than three entitlement filters.

  • If a model contains access-point or entitlement filters at a single level, it performs what's known as sensitive-access analysis: Filters identify access points whose assignment is inherently worthy of review, such as super user job roles.

  • If a model contains access-point or entitlement filters at two or more vertical levels, access points at all levels combine to define a conflict (as in the examples above).

Condition filters work differently. Each condition filter has an OR relationship to all other filters. In effect, all condition filters are applied when a model is run.

Keep these concepts in mind:

  • When you add an access-point or entitlement filter, it appears by default below the lowest access-point or entitlement filter in your model hierarchy.

  • When you add condition filters, they appear by default in a horizontal row beneath the access-point and entitlement filters. You can't move them from that position.

  • Arrows connect the filters, indicating the flow from one filter to another as they're evaluated.

  • You can drag and drop existing access-point and entitlement filters to new positions within the model: Drag a filter so that it overlays another access-point or entitlement filter. A dialog box appears; in it, click And or Or.

    If you select Or, the filter you dragged moves alongside the other filter. If you select And, the filter you dragged moves beneath the other filter. The arrows connecting the filters adjust themselves to reflect the new AND or OR relationship.

    You can't move a filter above the top filter in your model hierarchy, but you can move that top filter below any other.

  • You can incorporate filters into groups: First select those you want to include. You must select all the filters in a horizontal set, or adjacent filters in a vertical set. Hold down the Ctrl key as you click the filters you want. Then select Create Group. You can drag and drop groups in the same ways as individual filters. To dissolve a group, select it and click Remove Group.

    By default, each group you create is named "Group." Click the icon at the lower right corner of each group to assign it an individual name.

  • You may edit or delete a filter. Right-click on it and select its Edit or Delete option. Or, to edit, you may click on a blue icon at the lower right corner of the filter.

From either of the pages you use to create or edit a model, you can also run the model. From either of those pages or from the Models management page, you can view results from the most recent run of the model.

Access models are subject to a limit on the number of result records they can return. The default limit is 5,000, but an administrator may reduce this value in the Advanced Controls Configurations page. It's located in the Setup and Administration work area.

  • A model run may return records slightly in excess of the limit. That's because once a record of a user with an access conflict is included in the record set, all records involving that user must be included. When the limit is reached, analysis may continue until records are complete for all users already included in the return set. However, no records are added for users not already included in the return set.

  • Or, if global users are configured so that individual global user IDs are associated with more than one actual user, the model run may fall short of the limit.

  • The create- or edit-model page includes a check box labeled Override record limit and return all results for access model analysis. It's active only if an administrator has made an appropriate selection in the Advanced Controls Configurations page. If it's active, you can have a model run return all possible results: Select the check box and save the model before running it. If the check box is inactive, you can't bypass the record limit.

In the page to create or edit a model, you have two results options:

  • Run: The model runs, and the page remains open. A job number is displayed; make a note of it.

    To check the status of the model-analysis job, select the Monitor Jobs button. In the row for the job number you noted, determine when the job status reaches Completed.

    If the model has been run before, the new run overwrites the existing results (with no prompt to save or view them).

  • View Existing Results: A results page displays the results generated in the most recent run of the model. This option is available only if the model has been run at least once.

From the Models page, any model that's been run displays the number of model violations in a Results Count column. Click that number to generate the display of the most recent model results.

Note: When you edit an access model, any results already returned for the model are deleted. You must rerun the model to produce new results.

An access model returns a grid. Each row is a record of an access-point assignment to a user that the model defines as risky. Results include these values:

  • An Incident Information column reports the path to the access point that's the focus of the result record. It uses display names to identify roles in the path, but display names may not be unique.

  • An Incident Information Codes column reports the same access path, but it uses role codes to identify roles in the path. Every role code is unique.

  • A Group column identifies any access points that conflict with the Incident Information access point.

  • Role and Conflicting Roles columns identify the roles that grant access to these access points.

Other columns are self-explanatory. You may find that some of the columns you want to see are hidden by default. Click View > Columns to select the columns appropriate for your purposes.

In some cases, the assignment of a single role grants rights to access points a model defines as conflicting. You can filter the model results to display only those conflicts. Click the Conflicts within a single role check box.

As you review access model results, you may determine that some records are false positives: although they meet the model's risk definition, they don't pose actual separation-of-duties risk. This may be true, for example, in either of these cases:

  • A model defines a conflict between two access points, but a user's access to one of them is read-only. In particular, the conflict may involve a privilege whose path includes an aggregate privilege that grants read-only access.

    An aggregate privilege is a predefined role that combines one function security privilege with related data security policies. In some cases, the policies stipulate read-only access to data. For example, users may have access to a Manage Work Terms and Assignment privilege. That access would be read-only if granted through an aggregate privilege called View Work Terms and Assignment, but write-enabled if granted through a duty role called Manage Work Terms and Assignment.

  • A model defines a conflict between two access points, and one of them exists in the hierarchy of a role with "stripes." Modifications to striped roles may cause an access point to exist within a hierarchy but not actually grant access.

    Role stripes are versions of a role that apply to specific modules of Oracle Cloud. For example, there's a predefined Payables Invoice Creation duty role: ORA_AP_PAYABLES_INVOICE_CREATION_DUTY. There are also stripes of this role: ORA_AP_PAYABLES_INVOICE_CREATION_DUTY_OBI and ORA_AP_PAYABLES_INVOICE_CREATION_DUTY_CRM. They're used with Oracle Business Intelligence and Customer Resource Management, respectively.

    Note that you can no longer modify role stripes, so these false positives would be of concern only for modified stripes inherited from R12 or earlier.

To eliminate false positive results, create conditions to exclude them. Path conditions, for example, work well with false positives generated when users gain access to privileges through read-only aggregate privileges. The process involves these steps:

  1. Having run an access model, review its results to identify false-positive records. For example, look for paths that include aggregate privileges you know to be read-only. Or, look for paths including roles with stripes.

  2. Confirm that a given record is a false positive. Then create a condition to exclude it. For example, you might:

    • Create a user-defined access point that specifies the exact path of a false positive involving a read-only aggregate privilege. Then create a path condition to exclude that user-defined access point.

    • Create a conventional condition that uses the Access Point attribute, the Does not equal condition, and the name of a role that you know grants read-only access. For example, that role might be the View Work Terms and Assignment aggregate privilege. This would exclude records in which the role occurs anywhere in a path.

  3. Consider including related condition filters as elements of a global condition. For example, a global condition might contain all the path-condition filters that identify false positives involving read-only aggregate privileges. That way, each condition filter applies whenever any model would return the false positive it excludes.

  4. Rerun the model. You should find that it returns fewer records, and all of them pertain to genuine conflicts.

Read-only aggregate privileges and role stripes are only two examples of what may cause false-positive results. Ask questions about your setup whose answers suggest condition filters that can eliminate other false-positive results. Here are some samples.

If you answer yes to either of the following, you may want to add a Within Same equals Yes condition:

  • Do you consider it a risk if someone can both create and pay an AP invoice, but only in the same business unit?

  • Do you consider it a risk if someone can create and post to a journal, but only in one data access set?

If you answer yes to any of the following, you may want to create a user-defined access point, and then create a path condition to exclude it:

  • Have you disabled the ability to quick pay for a particular role?

  • Have you hidden the bank accounts tab on the supplier site?

  • Have you modified data security policies associated to a role, so that the role doesn't have certain access? Possibly even through use of custom SQL?

If you answer yes to either of the following, you may want to create a condition that excludes a role:

  • Are you in a development instance, and want to exclude users with super-user roles?

  • Do you want to exclude the supplier portal role because it returns only external users who are expected to create their own suppliers and invoices?

Synchronize Access Model Result Data for OTBI Reporting

You can use Oracle Transaction Business Intelligence (OTBI) to create analyses of access-model results. These analyses draw data from the Risk Management Cloud - Advanced Access Models Real Time subject area. To update this subject area with current results, you run a Report Synchronization job that refreshes result data for models you select.

The typical development process involves defining a model, running it, and reviewing results. If those results include false positives, or exclude records you had expected, you revise the model, run it again, and retest. This process may include multiple iterations. If you use an OTBI analysis to review results, you would run the Report Synchronization job after each run of the model. The fact that you select models as you run the job ensures efficiency, as you synchronize data only for the models you're interested in.

To run the Report Synchronization job:

  1. In the Advanced Controls work area, select the Models tab to open the Models management page.

  2. Select models to be synchronized. You can work from the complete list of models, or filter it. To select one model, click its row. To select a continuous set, click the first model in the set, hold the Shift key, and click the last model. To select a discontinuous set, hold the Ctrl key as you click model records.

  3. Expand the Actions menu and select its Synchronize Results in OTBI option. A message presents a job ID. Note the ID, then close the message.

  4. In the Models page, click the Monitor Jobs button. In the Monitor Jobs page, locate the row displaying the Job ID you noted, and track the progress of the synchronization.

Note: A separate Report Synchronization job, which is run from the Scheduling page in the Setup and Administration work area, does not update access-model data. That job synchronizes data in OTBI subject areas that support controls and control analysis in both Advanced Access Controls and Advanced Financial Controls, as well as Financial Reporting Compliance data.