Skip to main content

MSTR Restricting access to data: Security filters

https://www2.microstrategy.com/producthelp/10.5/SystemAdmin/WebHelp/Lang_1033/Content/Admin/Restricting_access_to_dataSecurity_filters.htm

Restricting access to data: Security filters

Security filters enable you to control what warehouse data users can see when that data is accessed through MicroStrategy. A security filter can be assigned to a user or group to narrow the result set when they execute reports or browse elements. The security filter applies to all reports and documents, and all attribute element requests, submitted by a user.
For example, two regional managers can have two different security filters assigned to them for their regions: one has a security filter assigned to her that only shows the data from the Northeast region, and the other has a security filter that only shows data from the Southwest region. If these two regional managers run the same report, they may see different report results.
Security filters serve a similar function to database-level techniques such as database views and row level security. For information about controlling data security at the data warehouse level, see Controlling access to data at the database (RDBMS) level.
For more information about security filters, see the following:

Security filter example


How security filters work


Creating and applying a security filter


Security filters and metric levels


Using a single security filter for multiple users: System prompts


Merging security filters

Security filter example

A user in the MicroStrategy Tutorial project has a security filter defined as Subcategory=TV. When this user browses the Product hierarchy beginning with the Category attribute, she only sees the Electronics category. Within the Electronics category, she sees only the TV subcategory. Within the TV subcategory, she sees all Items within that subcategory.
When this user executes a simple report with Category, Subcategory, and Item in the rows, and Revenue in the columns, only the Items from the TV Subcategory are returned, as shown in the example below.
external image Security_Filter_1.gif
If this user executes another report with Category in the rows and Revenue in the columns, only the Revenue from the TV Subcategory is returned, as shown in the example below. The user cannot see any data from attribute elements that are outside the security filter.
external image Security_Filter_2.gif

How security filters work

Security filters are the same as regular filters except that they can contain only attribute qualifications, custom expressions, and joint element lists. Relationship filters and metric qualifications are not allowed in a security filter. A security filter can include as many expressions as you need, joined together by logical operators. For more information on creating filters, see the Filters chapter in the Basic Reporting Guide.
A security filter comes into play when a user is executing reports and browsing elements. The qualification defined by the security filter is used in the WHERE clause for any report that is related to the security filter’s attribute. By default, this is also true for element browsing: when a user browses through a hierarchy to answer a prompt, she only sees the attribute elements that the security filter allows her to see. For instructions on how to disable security filters for element browsing, see To disable security filters for element browsing.
Security filters are used as part of the cache key for report caching and element caching. This means that users with different security filters cannot access the same cached results, preserving data security. For more information about caching, see Improving Report and Document Response Time: Caching.
Each user or group can be directly assigned only one security filter for a project. Users and groups can be assigned different security filters for different projects. In cases where a user inherits one or more security filters from any groups that she belongs to, the security filters may need to be merged. For information about how security filters are merged, see Merging security filters.

Creating and applying a security filter

You create and apply security filters in the Security Filter Manager. Make sure you inform your users of any security filters assigned to them or their group. If you do not inform them of their security filters, they may not know that the data they see in their reports has been filtered, which may cause misinterpretation of report results.
Prerequisites
To create security filters, you must have the following privileges:

Create Application Objects (under the Common Privileges privilege group)


Use Report Filter Editor (under the Developer privilege group)


Use Security Filter Manager (under the Administration privilege group)

To create and apply a security filter for a user or group


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to create a security filter for.

Create a security filter


3Select the Security Filters tab.


4Select one:


To create a new security filter, click New. The Security Filter Editor opens. For instructions on how to use this editor to create a filter, see the MicroStrategy Developer Help.


OR, to convert an existing filter into a security filter, click Import. Browse to the filter you want to convert and click Open. Specify a name and location for the new security filter and click Save.

Apply the security filter to a user or group


5In the left side of the Security Filter Manager, in the Security Filters tab, browse to the security filter that you want to apply, and select that security filter.


6In the right side of the Security Filter Manager, select Security Filters.


7Browse to the user or group that you want to apply the security filter to, and select that user or group.


8Click > to apply the selected security filter to the selected user or group.


9Click OK to close the Security Filter Manager.

To disable security filters for element browsing


1In Developer, log into a project. You must log in with a user account that has administrative privileges.


2From the Administration menu, point to Projects, and then select Project Configuration. The Project Configuration Editor opens.


3Expand the Project Definition category, and then select Advanced.


4Under Attribute element browsing, clear the Apply security filters to element browsing check box.


5Click OK to close the Project Configuration Editor.


6Restart Intelligence Server for your changes to take effect.

Security filters and metric levels

In certain situations involving level metrics, users may be able to see a limited amount of data from outside their security filter. Specifically, if a metric is defined with absolute filtering on a level above that used in the security filter’s expression, the filter expression is raised to the metric’s level. For information about metric levels and filtering in metrics, see the Metrics chapter in the Advanced Reporting Guide.
For example, consider a metric called Category Revenue that is defined to return the revenue across all items in each category. Its level expression is Target=Category, Filtering=Absolute. When a user with a security filter Subcategory=TV executes a report with the Category Revenue metric, the Category Revenue metric displays the total revenue for the category. The user’s security filter is effectively changed to show the entire Category in which TV is a Subcategory.
This behavior can be modified by using the top range attribute and bottom range attribute properties.

top range attribute specifies the highest level of detail in a given hierarchy that the security filter allows the user to view. If a top range attribute is specified, the security filter expression is not raised to any level above the top range.


bottom range attribute specifies the lowest level of detail in a given hierarchy that the security filter allows the user to view. If this is not specified, the security filter can view every level lower than the specified top range attribute, as long as it is within the qualification defined by the filter expression.
The top and bottom range attributes can be set to the same level.
For instructions on how to assign range attributes to security filters, see Assigning a top or bottom range attribute to a security filter.
The examples below use a report with Category, Subcategory, and Item on the rows, and three metrics in the columns:

Revenue


Subcategory Revenue, which is defined with absolute filtering to the Subcategory level


Category Revenue, which is defined with absolute filtering to the Category level
The user executing this report has a security filter that restricts the Subcategory to the TV element.

No top or bottom range attribute

If no top or bottom range attribute is specified, then at the level of the security filter (Subcategory) and below, the user cannot see data outside his or her security filter. Above the level of the security filter, the user can see data outside the security filter if it is in a metric with absolute filtering for that level. Even in this case, the user sees only data for the Category in which his or her security filter is defined.
In the example report below, the user’s security filter does not specify a top or bottom range attribute. Item-level detail is displayed for only the items within the TV category. The Subcategory Revenue is displayed for all items within the TV subcategory. The Category Revenue is displayed for all items in the Category, including items that are not part of the TV subcategory. However, only the Electronics category is displayed. This illustrates how the security filter Subcategory=TV is raised to the category level such that Category=Electronics is the filter used with Category Revenue.
external image Security_Filter_No_Limit.gif

Top range attribute: Subcategory

If a top range attribute is specified, then the user cannot see any data outside of her security filter. This is true even at levels above the top level, regardless of whether metrics with absolute filtering are used.
In the example report below, the user’s security filter specifies a top range attribute of Subcategory. Here, the Category Revenue is displayed for only the items within the TV subcategory. The security filter Subcategory=TV is not raised to the Category level, because Category is above the specified top level of Subcategory.
external image Security_Filter_Top_Limit.gif

Bottom range attribute: Subcategory

If a bottom range attribute is specified, the user cannot see data aggregated at a lower level than the bottom level.
In the example report below, the user’s security filter specifies a bottom range attribute of Subcategory. Item-level detail is not displayed, because Item is a level below the bottom level of Subcategory. Instead, data for the entire Subcategory is shown for each item. Data at the Subcategory level is essentially the lowest level of granularity the user is allowed to see.
external image Security_Filter_Bottom_Limit.gif

Assigning a top or bottom range attribute to a security filter

You assign top and bottom range attributes to security filters in the Security Filter Manager. You can assign range attributes to a security filter for all users, or to the security filters per user.
You can assign the same attribute to a security filter as a top and bottom range attribute. A security filter can have multiple top or bottom range attributes as long as they are from different hierarchies. You cannot assign multiple attributes from the same hierarchy to either a top or bottom range. However, you can assign attributes from the same hierarchy if one is a top range attribute and one is a bottom range attribute. For example, you can assign Quarter (from the Time hierarchy) and Subcategory (from the Products hierarchy) as top range attributes, and Month (from the Time hierarchy) and Subcategory as bottom range attributes.
Prerequisites
To modify security filters, you must have the Use Security Filter Manager privilege.

To assign a top or bottom range attribute to a security filter


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to modify security filters for.


3Select the Attributes tab.


4Browse to the attribute that you want to set as a top or bottom range attribute, and select that attribute.


5To apply a top or bottom range attribute to a security filter for all users:


aIn the right side of the Security Filter Manager, select Security Filters.


bBrowse to the security filter that you want to apply the range attribute to.


cExpand that security filter, and select either the Top range attributes or Bottom range attributes folder.


dClick > to apply the selected attribute to the selected security filter.


6To apply a top or bottom range attribute to a security filter for a single user or group:


aIn the right side of the Security Filter Manager, select Groups/Users.


bBrowse to the user or group that you want to apply the range attribute to.


cExpand that user or group and select the security filter that you want to apply the range attribute to.


dExpand that security filter, and select either the Top range attributes or Bottom range attributes folder.


eClick > to apply the selected attribute to the selected security filter for the selected user or group.


7Click OK to close the Security Filter Manager.

Merging security filters

A user can be assigned a security filter directly, and can inherit a security filter from any groups that she belongs to. Because of this, multiple security filters may need to be merged when executing reports or browsing elements.
MicroStrategy supports the following methods of merging security filters:

Merging related security filters with OR and unrelated security filters with AND (This is the default method for merging security filters)


Merging all security filters with AND
For the examples in these sections, consider a project with the following user groups and associated security filters:
GroupSecurity FilterHierarchy
ElectronicsCategory = ElectronicsProduct
DramaSubcategory = DramaProduct
MoviesCategory = MoviesProduct
NortheastRegion = NortheastGeography
You control how security filters are merged at the project level. You can change the merge settings in the Project Configuration Editor for the selected project, in the Security Filter category. After making any changes to the security filter settings, you must restart Intelligence Server for those changes to take effect.
Changing how security filters are merged does not automatically invalidate any result caches created for users who have multiple security filters. MicroStrategy recommends that you invalidate all result caches in a project after changing how security filters are merged for that project. For instructions on how to invalidate all result caches in a project, see Invalidating result caches.

Merging related security filters with OR and unrelated security filters with AND

By default, security filters are merged with an OR if they are related, and with an AND if they are not related. That is, if two security filters are related, the user can see all data available from either security filter. However, if the security filters are not related, the user can see only the data available in both security filters.
Two security filters are considered related if the attributes that they derive from belong in the same hierarchy, such as Country and Region, or Year and Month. In the example security filters given above, the Electronics, TV, and Movies security filters are all related, and the Northeast security filter is not related to any of the others.
Using this merge method, a user who is a member of both the Electronics and Drama groups can see data from the Electronics category and the Drama subcategory, as shown below:
external image Security_Filter_Drama_AND_Elec.gif
A user who is a member of both the Movies and Drama groups can see data from all subcategories in the Movies category, not just the Drama subcategory. A user who is a member of both the Electronics and Drama categories can see data from both categories.
If a user who is a member of the Movies and Northeast groups executes a report with Region, Category, and Subcategory in the rows, only data from the Movies category in the Northeast region is shown, as seen below:
external image Security_Filter_NE_AND_Movies.gif
Data for the Movies category from outside the Northeast region is not available to this user, nor is data for the Northeast region for other categories.

Merging all security filters with AND

You can also configure Intelligence Server to always merge security filters with an AND, regardless of whether they are related.
As in the first method, a user who is a member of both the Movies and Northeast groups would see only information about the Movies category in the Northeast region.
A user who is a member of both the Movies and Drama groups would see only data from the Drama subcategory of Movies, as shown below:
external image Security_Filter_Movies_AND_Drama.gif
Data for the other subcategories of Drama is not available to this user.
This setting may cause problems if a user is a member of two mutually exclusive groups. For example, a user who is a member of both the Movies and Electronics groups cannot see any data from the Product hierarchy, because that hierarchy does not contain any data that belongs to both the Movies and Electronics categories.
Prerequisites
To configure how security filters are merged, you must have the Configure Project Basic privilege.

To configure how Intelligence Server merges multiple security filters for a user or group


1In Developer, log into a project. You must log in as a user with administrative privileges.


2From the Administration menu, point to Projects, and then select Project Configuration. The Project Configuration Editor opens.


3Expand the Security Filter category, and then select General.


4Under Security Filter Merge Options, select one of the options:


Union (OR) Security Filters on related attributes, intersect (AND) Security Filters on unrelated attributes (see Merging related security filters with OR and unrelated security filters with AND)


Intersect (AND) all Security Filters (see Merging all security filters with AND)


5Click OK to close the Project Configuration Editor.


6Restart Intelligence Server for your changes to take effect.

Using a single security filter for multiple users: System prompts

system prompt is a special type of prompt that does not require an answer from the user. Instead, it is answered automatically by Intelligence Server. System prompts are in the Public Objects/Prompts/System Prompts folder in Developer.

Note the following:

Like other prompt objects, answers to system prompts are used to match caches. Therefore, users do not share caches for reports that contain different answers to system prompts.


The system prompts Token 1, Token 2, Token 3, and Token 4 are provided to support using an XQuery source to authenticate users for a MicroStrategy project. For steps to report on and authenticate using XQuery sources, see the Advanced Reporting Guide.

The User Login prompt is a system prompt that is automatically answered with the login name of the user who executes the object containing the prompt. It can provide flexibility when implementing security mechanisms in MicroStrategy. You can use this prompt to insert the user’s login name into any security filter, or any other object that can use a prompt.
If you are using LDAP authentication in your MicroStrategy system, you can import LDAP attributes into your system as system prompts. You can then use these system prompts in security filters, in the same way that you use the User Login system prompt, as described above. For instructions on how to import LDAP attributes as system prompts, see Using LDAP attributes in security filters.
For examples of how to use system prompts in security filters, see:

Simplifying the security filter definition process


Implementing a report-level security filter


Using database tables that contain security information

To create a security filter using a system prompt


1In Developer, from the Administration menu, point to Projects and then select Security Filter Manager. The Security Filter Manager opens.


2From the Choose a project drop-down list, select the project that you want to create a security filter for.


3Select the Security Filters tab.


4Click New. The Security Filter Editor opens.


5Double-click on the text Double-click here to add a qualification. The Filtering Options pane opens.


6Select Add an advanced qualification and click OK.


7From the Option drop-down list, select Custom Expression.


8Type your custom expression in the Custom Expression area. You can drag and drop a system prompt or other object to include it in the custom expression. For detailed instructions on creating custom expressions in filters, see the Filters chapter of the Advanced Reporting Guide.


9When you have finished typing your custom expression, click Validate to make sure that its syntax is correct.


10Click Save and close. Type a name for the security filter and click Save. The new security filter is saved.

Simplifying the security filter definition process

You can use a system prompt to apply a single security filter to all users in a group. For example, you can create a security filter using the formula User@ID=?[User Login] that displays information only for the element of the User attribute that matches the user’s login.
For a more complex example, you can restrict Managers so that they can only view data on the employees that they supervise. Add the User Login prompt to a security filter in the form Manager=?[User Login]. Then assign the security filter to the Managers group. When a manager named John Smith executes a report, the security filter generates SQL for the condition Manager='John Smith' and only John Smith’s employees’ data is returned.

Implementing a report-level security filter

You can also use the User Login system prompt to implement security filter functionality at the report level, by defining a report filter with a system prompt. For example, you can define a report filter with the User Login prompt in the form Manager=?[User Login]. Any reports that use this filter return data only to those users who are listed as Managers in the system.

Using database tables that contain security information

If your organization maintains security information in database tables, you can use a system prompt to build MicroStrategy security mechanisms using the database security tables. For example, you can restrict the data returned based on a user’s login by creating a report filter that accesses columns in your security tables and includes the User Login system prompt. You can also restrict data access based on two or more unrelated attributes by using logical views (database views) and the User Login system prompt in a security filter. For more information, including detailed instructions, on how to implement these examples, see MicroStrategy Tech Note TN11351.

Comments

  1. There is so much in this article that I would never have thought of on my own. Your content gives readers things to think about in an interesting way. Thank you for your clear information. Remote Wipe iPhone

    ReplyDelete
    Replies
    1. Mstr Restricting Access To Data: Security Filters >>>>> Download Now

      >>>>> Download Full

      Mstr Restricting Access To Data: Security Filters >>>>> Download LINK

      >>>>> Download Now

      Mstr Restricting Access To Data: Security Filters >>>>> Download Full

      >>>>> Download LINK Hd

      Delete
  2. Mstr Restricting Access To Data: Security Filters >>>>> Download Now

    >>>>> Download Full

    Mstr Restricting Access To Data: Security Filters >>>>> Download LINK

    >>>>> Download Now

    Mstr Restricting Access To Data: Security Filters >>>>> Download Full

    >>>>> Download LINK NW

    ReplyDelete

Post a Comment

Popular posts from this blog

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned.  Case  can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 ,  ReturnValue1 ,  Condition2 , ReturnValue2 ,...,  DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV  evaluates a single metric and returns different values according to the results. It can be used to perfo...

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to  Main.aspx  or  mstrWeb  (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Settings for Outer Join between metrics in MicroStrategy

Settings for Outer Join between metrics in MicroStrategy MicroStrategy adopts multi-pass logic to determine the execution plan for a report. This means that every metric is evaluated in separate SQL passes. Outer Joins come into play when MicroStrategy Engine merges the results from all SQL passes into one report. For a multi-pass report, different Outer Join behaviors can give the user completely different results. In addition, report metrics can be of different types which can, in some cases, influence the result of the outer join. In MicroStrategy, there are two settings that users can access to control Outer Join behavior : Formula Join Type and Metric Join Type . Metric Join Type: VLDB Setting at Database Instance Level Report and Template Levels Report Editor > Data > Report Data Options Metric Level   Metric editor > Tools > Metric Join Type Control Join between Metrics Formula Join Type: Only at Compound/Split...

Control the display of null and zero metric values

Show   Control the display of null and zero metric values in a grid report You can determine how to display or hide rows and columns in a grid report that consist only of null or zero metric values. You can have MicroStrategy hide the rows and columns in the following ways: Hide rows and columns that consist only of null metric values Hide rows and columns that consist only of zero metric values Hide rows and columns that consist only of null or zero metric values (default) Once you have defined how MicroStrategy hides null and zero metric values in the grid, you can quickly show or hide the grid using the Hide Nulls/Zeros option in the Data menu, as described below, or by clicking the  Hide Nulls/Zeros  icon  in the Data toolbar. To determine how null and zero metric values are displayed or hidden in a grid report Open the report in Edit mode. From the  Tools  menu, select  Report Options . The Report Options...

Images in Microstrategy PDF Export shows Red X

When exporting a report containing an image attribute form (using an ApplySimple statement) to PDF in MicroStrategy Web 9.4.1 and 10.x, with the Intelligence Server running on Linux, the image in the exported PDF report appears as a red "X". When exporting a report containing an image attribute form (using an ApplySimple statement) to PDF in MicroStrategy Web 9.4.1 and 10.x, with the Intelligence Server running on Linux, the image in the exported PDF report appears as a red "X" as shown below: However, the images in the report display properly when the report is executed in MicroStrategy Developer and Web. Furthermore, when the report is exported to PDF on Desktop (with the original images saved in WebASPX\Images), the images in the report display properly, as indicated below: CAUSE This is expected behavior. When the report is displayed in MicroStrategy Developer and Web, or when the report is exported to PDF from MicroStrategy Dev...

Types of filters in Microstrategy

Types of filters in Microstrategy Below are the types of filters: 1. Attribute qualification filter These types of qualifications restrict data related to attributes on the report. a) Attribute form qualification Filters data related to a business attribute’s form(s), such as ID or description. •  For example, the attribute Customer has the forms ID, First Name, Last Name, Address, and Birth Date. An attribute form qualification might filter on the form Last Name, the operator Begins With, and the letter H. The results show a list of customers whose last names start with the letter H. b) Attribute element list qualification Filters data related to a business attribute’s elements, such as New York, Washington, and San Francisco, which are elements of the attribute City. • For example, the attribute Customer has the elements John Smith, Jane Doe, William Hill, and so on. An attribute element list qualification can filter data to display only those customer...

Personalizing file locations, email and file subscriptions using macros in Microstrategy

Personalizing file locations MSTr allows to dynamically specify the  File Location  and  Backup File Location  in a file device using macros.  For example, if you specify the  File Location  as  C:\Reports\{&RecipientName}\ ,  all subscriptions using that file device are delivered to subfolders of  C:\Reports\ . Subscribed reports or documents for each recipient are delivered to a subfolder with that recipient’s name, such as  C:\Reports\Jane Smith\  or  C:\Reports\Hiro Protagonist\ . The table below lists the macros that can be used in the  File Location  and  Backup File Location  fields in a file device: Description Macro Date on which the subscription is sent {&Date} Time at which the subscription is sent {&Time} Name of the recipient {&RecipientName} User ID (32-character GUID) of the recipient {&RecipientID} Distribution Services add...

Prompt-in-prompt(Nested Prompts) in Microstrategy

Prompt-in-prompt(Nested Prompts) in  Microstrategy Nested prompts allows you to create one prompt based on the other and other bases on another, nested prompts allows us to prompt the highest level(Like year) to middle level(like Quarter, then to the low level(like Month). Here you can see how to  create a 3-level deep nested prompt that will prompt the user to select a year, then a quarter within that year, then a month within that quarter. Prompt-in-prompt is a feature in which the answer to one prompt is used to define another prompt. This feature is only implemented for element list prompts . The following procedure describes how to achieve this: Create the highest level filter. This is a filter which contains a prompt on an attribute element list. Create a filter on the attribute "Year." Click "prompt on attribute element list" and click "Next" through the rest of the screens to accept the default values. Do not set any additio...

Types of result caches in Microstrategy

Types of result caches Microstrategy The following types of  result caches are created by Intelligence Server: • Matching caches • History caches • Matching-History caches • XML caches All document caches are Matching caches; documents do not generate History caches or XML caches. Intelligent Cube reports do not create Matching caches. Matching caches Matching caches  are the  results of reports and documents that are retained for later use by the same requests later on. In general, Matching caches are the type of result caches that are used most often by Intelligence Server. When result caching is enabled, Intelligence Server determines for each request whether it can be served by an already existing Matching cache. If there is no match, it then runs the report or document on the database and creates a new Matching cache that can be reused if the same request is submitted again. This caching process is managed by the system administrator and ...