Using the Manage Segment Value Security Rules Spreadsheet

Follow these guidelines when creating new rules and new rule assignment records in the Manage Segment Value Security Rules Spreadsheet.

  • Always navigate to the Rules sheet first to initialize your session, then second to the Rule Assignments sheet. Don’t navigate directly to the Rule Assignments sheet right away because this will result in an error for your session with the spreadsheet.
  • Click the Upload command on the Manage Segment Value Security tab once you’ve completed your entries on the worksheet to save these records to the application.
  • Upload the Rules worksheet first before completing and uploading the Rule Assignments worksheet because the assignments in the latter worksheet reference the rules. The rules need to be successfully saved to the application first before they can be assigned to users.
  • Work with only one secured value set at a time per session. Otherwise, the application can't properly identify which value set is the focus if multiple secured value sets are simultaneously being worked on. As part of its initialization, the spreadsheet establishes a connection and value set of focus.

Create Rules

The Rules worksheet of the Manage Segment Value Security Rules spreadsheet is for defining segment value security policies.

Policies can include one or more segment value security condition filters and are associated with a segment value security role. The segment value security role serves as the conduit to pass the security policy to users.

A policy can have a one-to-many relationship with condition filters. You can do this in the spreadsheet by using the same policy name across multiple rows. The different condition filters defined in these multiple rows will be treated as a group that's associated with that one policy. This helps you adhere to the best practice of keeping in check the number of security policies defined for a secured value set and keeping setups manageable.

Columns are either policy-level attributes or condition filter-level attributes. Policy-level attributes must share the same value across multiple rows for the group of condition filters that are part of that same policy. Values for the condition filter-level attributes representing the different condition filters that you want to apply to the same policy will vary across the rows.

Enter attribute values in the order in which the columns appear in the worksheet, starting with the policy name.

This table lists the attribute columns on the Rules worksheet and their properties.

Attribute Required Updatable Policy or Condition Filter Attribute
Policy Name Yes No Policy
Policy Description No Yes Policy
Segment Value Security Role Name Yes No Policy
Operator Yes Yes Condition Filter
From Value (Used with all operators other than All Values) Yes Yes Condition Filter
To Value (Used with Between operator only) Yes Yes Condition Filter
Tree Code (Used with hierarchical operators only) Yes Yes Condition Filter
Tree Version (Used with hierarchical operators only) Yes Yes Condition Filter
Policy Start Date Yes No Policy
Policy End Date No Yes, if the policy is active, that is, the policy end date is today’s date or later. Policy
Mark for Deletion No Yes Condition Filter

Here’s more information about each attribute to help you prepare the Rules worksheet.

Policy Name

Identifies the specific condition to segment value security role association. The name must be unique within the individual secured value set. The application automatically stores the capitalized policy name to help minimize confusion and anomalies when referencing the policy’s name.

Policy Description

Provides a summary of the scope, purpose, or other pertinent information about the policy.

Segment Value Security Role Name

Identifies the predefined role to which you’re assigning the segment value security policy. Double-click within the cell to open a dialog box, where you can select the role to insert into that cell. To form a complete user rule assignment, you must also assign the segment value security role of the policy to the users you want to assign the policy.

Operator

Indicates how to evaluate the succeeding values specified in the row for the purpose of determining what account values of the secured value set are being granted. This is a key attribute of a segment value security condition filter.

Related condition rows for the same policy created using the spreadsheet will always be set to the Match Any option or to using the Or conjunction when stringing together the various condition filter rows for the same policy to determine what account values are involved. This is also the default match setting even if it's a policy with just a single condition filter row.

This means that the account values being granted by the policy just need to match one of the condition rows stipulated in the group, rather than simultaneously match every one of the condition rows in that group, which would more than likely result in a nonmatch, or no account value, because an account value is unlikely to satisfy every one of those conditions.

This table describes the operators you can use in the condition filters.

Operator Description
All Values

Provides access to all account values in the value set.

Equal to

Provides access to a specific account value. When the specified value is a parent account, access applies to that parent value only, in all trees and tree versions that include that parent. The rule doesn't provide access to any of its descendants.

Not equal to

Provides access to all values, except the one detail/child or a parent value that you specify. In the case of a parent value, the exclusion only applies specifically to that parent value itself, and not any of its descendant parent and detail or child values.

Caution: Here are some important points about this operator.
  • Use this operator carefully and sparingly.
  • Don't use it in multiple condition rows for the same policy or in different policies assigned to the same security value security role for a given secured value set. The different conditions could end up canceling each other out, resulting in unintended access being granted to account values you want to secure.

    For example, let's say you have a policy with two condition rows. You define the first condition as Not Equal To account value 100 and the second condition as Not Equal To account value 200. The list of values for the segment is going to show both 100 and 200, among other values. That's because an account value can meet any one of the conditions for the rule to apply. The value of 100 meets the Not Equal To 200 condition and the value of 200 meets the Not Equal To 100 condition.

Between

Provides access to the account values included in the range of values specified in the From and To Value columns. When the range of values includes a parent account, access applies to that parent value only, in all trees and tree versions that include that parent. The rule doesn't provide access to any of its descendants, unless they're part of the specified range.

Contains

Provides access to account values that contain the specified value. When the matching value is a parent account, access applies to that parent value only, in all trees and tree versions that include that parent. It doesn't provide access to any of its descendants unless those descendants also happen to match the condition.

Ends with

Provides access to account values that end with the specified value. When the matching value is a parent account, access applies to that parent value only, in all trees and tree versions that include that parent. It doesn't provide access to any of its descendants unless those descendants also happen to match the condition.

Starts with

Provides access to account values that start with the specified value. When the matching value is a parent account, access applies to that parent value only, in all trees and tree versions that include that parent. It doesn't provide access to any of its descendants unless the descendants also happen to match the condition.

Is descendant of

Provides access to the specified parent account value and all its descendants. Descendants include middle level parent accounts and nonparent accounts throughout all that parent's hierarchical branches, from the root to the leaf nodes.

Is last descendant of

Provides access to the specified parent account value and to the account values at the leaf nodes of that parent. Access doesn't include intermediate parent account values along the hierarchical branches.

Note: For the Is descendant of and Is last descendant of operators, the security rule provides access across all tree versions of the specified hierarchy that reference the accounts that are granted, as well as all hierarchies associated with the same value set of the specified hierarchy. It uses the parent value rollup of the rule’s specified hierarchy as the basis for determining which values are granted and applies date effectivity to identify which is the effective version based on the system date for the rule’s specified hierarchy and the account values included in that version. For more information see the Reporting on General Ledger Balances Cubes Reports with Account Hierarchies topic.

From Value

Specifies the value to apply for the specified condition filter operator in determining what account values to consider. You must specify a valid account value when using any condition filter operator, except for Between, Contains, Ends with, and Starts with. This allows for some additional flexibility to include account values that have yet to be created.

To Value

Specifies the value to apply for the Between condition filter operator in determining what account values to consider. This is the ending value for the range and allows for some additional flexibility to include account values that have yet to be created.

Tree Code

Identifies the tree to reference when you select a parent account value for the condition. This is a required attribute if you’re using the Is descendant of and Is last descendant of operators. These operators are also the only valid operator choices when you specify a tree code for the row. Double-click within the cell to open a dialog box, where you can select a valid tree code for the secured value set that you’re working with.

While a distinct tree code is associated with each segment in a chart of accounts, as specified by the Default Hierarchy value in the chart of accounts structure setup, you can refer to any tree that’s defined for the secured value set.

Note: The trees that you specify in a rule must be flattened. This contrasts with trees that are published to balances cubes, which don’t need to be flattened. If your security rules refer to trees that are published to the balances cubes, then the trees must be flattened. Otherwise security enforcement won’t work in balances cube-based reports and queries.

Tree Version

Identifies the tree version of the selected tree code to reference when you select a parent account value for the condition. This is a required attribute if you’re using the Is descendant of and Is last descendant of operators. These operators are also the only valid operator choices when you specify a tree version for the row.

Policy Start Date

Specifies when the policy begins. You must specify a start date that’s no earlier than the current system date when creating the policy because a policy can’t be effective for any earlier date than when it comes into existence. You can also specify a future date.

This attribute must share the same value among related rows of multiple condition filters that are tied to the same policy.

Note: When you add new condition filter rows to an existing policy, the start date for the new rows must match the start date of the original policy rows because this is a policy-level attribute.

Policy End Date

Specifies when the policy ends. You must specify an end date that's no earlier than the policy start date. If you don't specify an end date, then the policy is in effect indefinitely.

You can update the end date on an existing policy as long as the specified end date is today or a date in the future. That is, the rule is still active. The new end date must be at least today’s date or a date in the future. There’s no requirement for the new end date to be later than the current end date.

For example, let’s say today’s date is January 27 and the end date for a rule is set to January 31. A day later, on January 28, you can update the end date to January 28 or later. It doesn’t have to be set beyond January 31, which is the original end date. However, you can’t update the end date from January 31 once it’s February 1.

This attribute must share the same value among related rows of multiple condition filters that are tied to the same policy.

Note: When you add new condition filter rows to an existing policy, the end date for the new rows must match the end date of the original policy rows, if there is one, because this is a policy level attribute.

For audit purposes, segment value security policies are never deleted. The Policy End Date attribute is used instead to indicate that the policy is no longer applicable.

Mark for Deletion

Indicates whether to delete the selected condition filter row and remove it from the policy. This deletion indicator safeguards users from accidentally deleting condition filter rows for a policy from the application by requiring users to explicitly indicate this action for a given row. This is a condition-level attribute and individual condition filter rows associated with the policy can be specifically marked for deletion.

Note: If the only condition filter row for a given condition is marked for deletion, the application will automatically end date the policy and no longer display such empty policies in the spreadsheet, that is, a policy with no condition filter rows.

Create Rule Assignments

The Rule Assignments worksheet of the Manage Segment Value Security Rules spreadsheet is for assigning policies to users, qualifying under which business function and security context the policy assignments are applicable for the user, and granting either a read only, or a read and write access level.

Enter attribute values in the order in which the columns appear in the worksheet.

This table lists the attribute columns on the Rule Assignments worksheet and their properties.

Attribute Required Updatable
User Name Yes No
Policy Name Yes Yes
Role Name (Display Only) Not applicable Not applicable
Business Function Yes Yes
Security Context Yes Yes
Security Context Value Yes Yes
Access Level Yes Yes
Start Date Yes No
End Date No Yes

Here’s more information about each attribute to help you prepare the Rule Assignments worksheet.

User Name

Identifies the user for the rule assignment. Select one of the following options:

  • Select specific: Select to specify the sign in name of the user who's to be assigned the rule or policy for the given secured value set.
  • Select all assigned to the policy role: Select to share the rule assignment with all users who are assigned the role for the specified policy.

Policy Name

Identifies the policy to assign to the user. Double-click within the cell to open a dialog box, where you can select a valid policy for the given secured value set.

Role Name

Identifies the role associated with the policy selected for the rule assignment. This is a display-only field and is shown as additional information when searching and retrieving a rule assignment from the application.

Business Function

Identifies the business function that the rule assignment for the user applies to. The list corresponds to the product modules that support segment value security by business function.

Note: To create a rule assignment for a given business function, that function must be enabled for segment value security enforcement.

This table lists the business functions and their corresponding product modules.

Business Function Product Module
Assets Oracle Assets
General Ledger Oracle General Ledger
Payables Oracle Payables
Provider intercompany Oracle Intercompany
Receivables Oracle Receivables
Receiver intercompany Oracle Intercompany

Selecting any of these business functions automatically includes Oracle Subledger Accounting, a product module that integrates between General Ledger and the subledgers.

Note: The 2 Intercompany business functions allow you to further differentiate whether the rule assignment to the user for the specified intercompany organization is applicable when the intercompany organization is being used by the user to transact in the capacity of a provider or a receiver.

You can also select All business functions if the grant of the policy to the user isn’t limited for just a particular business function. It can also be used in the case of the Intercompany module when the rule assignment to an Intercompany user applies no matter when the specified intercompany organization is transacting in the capacity of a provider or receiver.

The selection for this attribute also determines which choice is valid for the following Security Context attribute because the security context corresponds to the selected business function.

Security Context

Identifies the type of security context under which the policy or rule assignment should be valid for the user. You must select a security context that correlates to the selected business function. For example, for the General Ledger business function, the applicable security context is data access set.

Here are the possible choices:

  • Business unit: Applies to the Payables and Receivables business functions.
  • Asset books: Applies to the Assets business function.
  • Data access set: Applies to the General Ledger business function.
  • Intercompany organization: Applies to the Intercompany business functions.
  • All security contexts: Applies to any business function.
Note: If you want to include the business unit for both the Payables and Receivables business functions, select All business functions for the Business Function attribute.

The selection for this attribute also determines which choice is applicable for the following Security Context Value attribute because the context value corresponds to the selected security context.

If it isn’t necessary to limit a user’s policy to be applicable for a particular security context and security context value, you can select All security contexts. This selection can be paired with the selection of All business functions, or a specific business function, in the preceding column. For the former, this means that the rule assignment or policy grant for the user will be applicable no matter what business function, security context, and security context value that user is working with. It effectively means that this policy is applicable for the user all the time. If a specific business function is selected, the rule assignment is applicable to the user only for the selected business function, but without regards to the security context value that user is working with.

If you select All security contexts, the only valid choice for the Security Context Value attribute is All security context values.

Security Context Value

Specifies the security context value for the selected security context type and business functions in the preceding 2 columns under which the policy or rule assignment will be effective for the user. The possible choices include the valid asset books, business units, data access sets, or intercompany organizations in the system, depending on the security context that was selected for the rule assignment.

For the policy or rule assignment to be a relevant and effective one for the users to which they're assigned, ensure that the selected asset book, business unit, data access set, or intercompany organization for that rule assignment is one that's assigned to the user in the Manage Data Access for Users page and to which the user has been granted data access.

There's also a choice of All security context values, which is the only valid choice when All security contexts is selected for the preceding Security Context column. This would make this policy always applicable to the user, no matter what data access context that user is working with.

Access Level

Indicates whether the user rule or policy assignment for the given business function, security context, and context value should be granted on a Read only or Read and write basis.

For rule assignments that are set to Read only, the account values allowed will only be applicable in read-only features, such as an inquiry page or a report. Where the product feature involves update capabilities for accounting data, these account values with read-only access will not be available to the user.

For rule assignments that are set to Read and write, the account values allowed will be applicable in read-only features as well as those features that involve update capabilities for accounting data.

Start Date

Specifies when the user rule assignment begins. The date can’t be earlier than the current system date when you're creating a new user rule assignment. This is because a rule assignment can't be effective any earlier than the date when it's created. You can also create a user rule assignment with a future date as the start date.

Note: The start date can’t be any earlier than the start date of the policy referenced in the rule assignment.

End Date

Specifies when the user rule assignment ends. This date can't be earlier than the user rule assignment’s start date and any later than the end date of the policy referenced in the rule assignment.

You can update the end date on an existing user rule assignment as long as the current end date is today or a date in the future. That is, the rule assignment is still active. The new end date must be at least today’s date or a future date, but still within the end date of the policy referenced in the rule assignment. There’s no requirement for the new end date to be later than the current end date for the user rule assignment.

For example, let’s say today’s date is January 27 and the end date for a rule assignment is set to January 31. A day later on January 28, a new end date can be set to January 28 or later as long as it doesn’t exceed the end date of the policy referenced in the rule. It doesn’t have to be set beyond January 31, which is the original end date. However, you can’t update the end date on the rule assignment from January 31 once it's February 1.

For audit purposes, records of segment value security policy assignments to users are never deleted. The rule assignment End Date attribute is used instead to indicate that the policy assignment is no longer applicable.

Edit Rules and Rule Assignments

To edit existing rules and rule assignments, it's very important, and will always be required, to first download the records from the application.

This ensures that you're working with the current version of the rule or rule assignment that’s stored in the application. You can download existing rule and rule assignment records for the secured value set for review or edit by using the Search command on either worksheet on the Manage Segment Value Security tab.

Once you've downloaded the records you want to update, make your edits, and upload your changes to save them to the application. You can also create rules and user rule assignments in the same spreadsheet that you're editing.

On the Rules worksheet, you can filter your search for policies by policy name, segment value security role, or both, by specifying relevant search strings for these fields.

On the Rule Assignments worksheet, you can filter your search for user rule assignments by user name, policy name, or both, by specifying the relevant search strings for these fields.