CRW DOCUMENTATION. The schema is a CoreTrac xml file that defines a set of databases to work with.

Transcription

1 CRW DOCUMENTATION OVERVIEW The Custom Report Writer (CRW) is a powerful reporting application that provides direct access to the data within Resource One. CRW is essentially an open-ended tool that exposes a limitless set of options and configurations. To tap into the potential of this reporting tool, it is important to understand the workflow involved in setting up and running reports. TOOLTIPS Throughout the application, CoreTrac has provided contextual help in the form of tooltips. Wherever an information icon appears, simply hover over it to trigger the tooltip. THE SCHEMA The schema is a CoreTrac xml file that defines a set of databases to work with. CONNECTIONS To generate reports, a set of connection strings must be created, to work in conjunction with the schema. These connection strings are currently limited to MS SQL Server with other provider types coming in the future. As with any MS SQL Server connection string, trusted connections or SQL Server credential connections are accepted. A typical scenario for complimenting Resource One installation has one connection string for the Bank database and one for the CTAdmin database. It is important to note that the Database Name specified will/must be the same name used in the XML schema (described below). This is how the application knows where to go looking for data when running reports. SCHEMA EDITOR The application uses one [schema].xml file which must be located in the \xmloutput folder of the application, and whose name is specified in \configs\envsettings.xml. The schema defines every database table and column available to report on, as well as custom, user defined virtual columns, extension columns and more.

2 The figure above shows the schema editor in use. This is simply a tree UI of the [schema].xml file. The file is initially generated by CoreTrac and varies from customer to customer. The basic structure is hierarchical and pretty self- explanatory. For a list of possible actions, right click on any node text. Tables, joins, columns, filters and entities are all editable and presented below. Clicking on a table (e.g. Accounts here) will bring up the table editor. The basic information can be changed. Of important note, the Friendly Name is used throughout CRW as a visual alias to the table. In this case it allows the Activity table to be further refined through Filters (See below) and given special meaning, even though it still physically references the Activity table. The checkbox Is Primary sets whether or not this table will be available as a starting point table when creating reports.

3 Clicking on any join (child node of Joins) will bring up the join editor. These represent actual foreign key constraints in the database. Additionally, joins can be defined which are not actually present in the database. This is handy for databases where normalization is not optimal or true foreign keys are lacking. CRW will only use the joins defined here to offer links to data columns in the UI during report creation, so it is up to the discretion of the administer to determine which non-foreign key joins might make sense. Clicking on any column (child node of columns) will bring up the column editor. These represent actual columns in the database and therefore must exist at runtime. Again, there is a friendly name that can be set. Of important note, are the values list, and Is HTML checkbox

4 1. Values list a. For character type fields (varchar etc.) the administrator can specify that this column, when used as a filter should present checkboxes with fixed possible values. This essentially overrides the data in the table and is useful for status and type tables. Separate values with pipes, (e.g. Yes No Maybe ) 2. Allow Checkboxes a. For character type fields (varchar etc.) the administrator can specify that this column, when used as a filter should present checkboxes using the actual data from the table (distinct values). 3. Is HTML a. Flags a field as one with HTML character data so that report rendering will properly strip out any HTML. Virtual columns are used to perform case switching and concatenation on existing columns. This example checks for null values and equality, returning a numeric representation of true/false. It is important to note the [[self]] construct. This is CRW meta syntax to generically refer to this database and table. The report engine will use this when constructing the query. The Title is the friendly name that will be shown in the UI.

5 Extension columns take the concept of virtual columns to another level and provide a lot of flexibility. This is where row based T-SQL sub-queries are possible. Care must be taken when defining Extension columns because this flexibility can directly affect performance. For an extension column to be valid, you must define each piece of the sub query: 1. Value

6 a. The value must be an actual field in the database (not necessarily in the schema). As described in the virtual column section, [[self]] is used to refer to the table under which this column is being defined. [[id:1]].{columnname}, [[id:2]].{columnname} etc. may be used to reference columns from joined tables (defined in the join text box). In this example, the column detail_value in the table activity_detail is defined. 2. Join a. SQL joins are defined here using the CRW meta syntax. i. [[database]] is meta syntax to reference the database that contains this extension column ii. [[id:#]] defines an alias, just like in actual SQL alias which is used to identify each joined table iii. [[self]] is used to refer to the table that contains this extension column. 3. Where a. Used to limit the result set of this query. The same meta syntax is allowed here. If no where clause is needed, use 1=1 As mentioned in the Virtual column section, the Title is the friendly name that will be shown in the UI. Is HTML flags a field as one with HTML character data so that report rendering will properly strip out any HTML. Reverse columns are a method by which data from tables with a foreign key column to this table can be accessed by CRW from this table. They essentially build a bridge from a column in this table to another in a 1-many fashion. The target database, table and column represent the other table field and the Column is the local field in this table. No actual foreign key is required to create a reverse column. The Title is the friendly name that will be shown in the UI.

7 Each table has a Filter node, which the administrator may use to restrict any query which accesses the table. In this example, the table is Activity (Friendly name is Accounts) whose data must be restricted by status to be an Account. Use the CRW meta syntax as in other schema sections to reference this table and build a where clause, (e.g. [[self]].columnname). Each table has an Entity node which is an optional item used with Resource One integration. It is used when reports in CRW are integrated into Resource One as Custom Lists. In those lists, a grid of resulting data is displayed in R1 where each row has an icon and a detail link. Here the icon is specified as a simple gif file. This file must exist in R1 since it is displayed in R1 and not CRW. The [[CALLER_URL]] is a meta syntax to use the current R1 domain URL. [[ID]] is an alias to the primary key of each row in the primary table of the overall query. In this example, it is the Account Id.

8 PERMISSIONS The CRW security system is modeled on the ubiquitous Group/Permission/Member model. Users are added and managed in groups. Groups can then be given permissions. The permission system is inclusion based which means that users and groups must be given permission to various functionality and do not start out with any permissions be default. GROUPS Groups are managed in the grid as seen here. Use the clone functionality to quickly create many similar groups before pruning or adding unique permissions to each group. It should be noted that there is no need to create an R1Admin group since this is an elevated privilege that is set on the user level.

9 APPLICATION PERMISSIONS Application permissions are used to control access to the application itself. The View checkbox is used to grant access. Schema Administration o View Connections menu link o View Create schema menu link o View Edit schema menu link Manage Schema o Access to Edit Schema page Create Schema o Access to Create Schema page Manage Connections o Access to Connections page Manage Reports o Access to Edit Report page o Access to Edit Union Report page o Access to Manage Reports page Create Reports (Not Used) View Reports o Access to List Reports page o Access to View Report page Report Administration o View Images menu link o View Yearly Quarters menu link o View Create/Edit reports menu link Manage Images o Access to Image Management page Export Report o View Export menu link Import Report o View Import menu link o Access to Export page o Access to Import page Manage Security o View Groups menu link o View Users menu link o Access to Edit Group page o Access to Edit User page o Access to Manage Groups page o Access to Manage Users page Import Users (Not Implemented) Impersonate (Not Implemented)

10 DATABASE PERMISSIONS Database permissions control access to individual tables and columns in the CRW schema. The UI comprises two data grids. The left one is the complete list of CRW tables as defined in the current schema. The right grid is populated when a table link from the left grid is clicked. There are three permissions to set: View this controls whether or not a user, at report runtime will be able to see the table or column. If a table or column is used in the report either as a filter, or group or simple column, that part of the report will be removed at runtime if the user does not have permission to view it. Edit this controls whether or not an administrator will be able to see and access the table or column in the schema during report creation. Export is not used at this time. USERS Users are managed on their own page with basic search available to locate individuals.

11 GENERAL INFORMATION The basic information about a CRW user is managed here. A few important fields to note: 1. Source is used when CRW and Resource One are integrated. A value of R1 will signal that Resource One should attempt to use this user record when performing a real-time triggered sync. 2. Windows Account - is used when windows authentication is turned on for CRW. It must contain the domain account of the user and is case insensitive (e.g. domain\username). 3. Access Level is a user level override to the basic security group system a. User No special privileges b. Administrator Schema is not restricted for this user c. R1Admin CRW is not restricted for this user.

12 RESOURCES IMAGE MANAGEMENT The CRW image management tool allows the report administrator to upload and save images to be used across various reports. The images are stored in the database with a maximum image size of 1Mb. The following figure shows the image management screen. Previously uploaded images are listed with a preview, name, alternate text (if the image is missing) and hover title. To edit an image, click on the edit icon and to upload a new image click on Add Image. Click on the trashcan icon to delete any image. Any report which uses an image which is deleted, will have a blank spot in the output report where the image was once rendered. The image upload and edit form is simple. Select an image to upload and provide an optional name, alternate text and hover title. If Name is omitted, the image name will be used. Upon editing an existing image, the image does not have to be re-selected. The preexisting image will be maintained, allowing for updating just the name, alternative text or title.

13 YEARLY QUARTERS The quarter management system allows for the flexibility to define quarters for a customer in a unique and meaningful way. The name of the quarter will be available in the report filter editor as a way of specifying which quarter a filter applies to, and what the timespan of that quarter means to the Financial Institution. Any number of quarters with custom ranges is possible in the system.

14 REPORTS CRW supports two distinct types of reports, which correspond to the type of SQL that is generated to execute at run-time. There are Reports and there are Union Reports. A standard report should be thought of as a select statement, albeit a potentially complex one. A Union Report is one which depends upon and uses other standard reports (and their queries) to generate a UNION type of query. This type of report is discussed in its own section. REPORT MANAGEMENT The user may view a list of existing reports (templates) by clicking on Manage Reports. This list will contain reports that are installed by CoreTrac, to be used as templates for other reports, as well as any other reports generated by an administrative user. Below is a sample screenshot of the report management screen. CLONING A REPORT The user may copy an entire report including the name, category, description and all criteria into a new report. This is useful to use an existing report as a template, and then make changes or additions to the report parameters/criteria. When a report is cloned, the new Name will automatically have (copy) added to the name. This is just for indicating which report is the newly copied one. The report name may be subsequently changed at any time. DELETING A REPORT Any report which is not locked (see below) may be deleted. Upon clicking the trashcan icon, the user is prompted to confirm that he/she wants to delete the report. Confirming the delete will permanently delete the report and it may not be recovered. LOCKING A REPORT Any report may be locked from further editing or deleting by clicking on the unlocked icon. When a report is locked, the icon changes to a locked icon and only by selecting the locked icon, will the report become unlocked again, ready for changes. This is to protect reports from accidental changes and deletion. It should be noted that a report can be cloned whether it is locked or not.

15 RUNNING A REPORT See section below for details about running a report. EDITING A STANDARD REPORT The most important concept to grasp with the CRW is the workflow. The concept behind this application is that the report administrator creates a custom query against databases which have a schema defined in the application (See Schema Management) and presents only the information that is of interest to him/her. The query is the heart of the report and must be carefully thought out before sitting down to create the report. As we will show, the report must be set up in a logical process with a clear idea of the finished report in mind at all times. The user should follow this workflow: Select the columns that will appear across the whole report as tabular data. These columns will be consistent from page to page Set up any conditionals (See Conditionals) which will be used to control which filters will be shown to the end-user. Set up all of the filters to limit and constrain which data is shown in the final report. Things to consider Date range filters Type/status filters Location filters (Regions, District, Branches etc.) User filters Set up groups and summaries. Consider how the report will be logically broken up into sections (groups) and create accordingly. Within each group, set up summaries of numeric data such as dollar amount summaries and activity accounts etc. Building a report from scratch is a good way to learn how the Custom Report Writer works. It should be noted that this application is essentially a query tool attached directly to one or more databases. This makes it a very powerful and complex tool which will take some getting used to. In order to obtain desirable results, consider the following approach when designing a report. The report query should be designed with a clear idea of the desired end results. Consider sketching out what data columns and summaries should be in the final report. Choose a report focus carefully (more about that below). Select the desired columns before filtration, groups or summaries. Set up groups and summaries according to the original report design plan Finish off the report with filtration to narrow down the results of the final report

16 Below is a screen shot of a typical report during edit. Each set up area is contained on a tab. It must be noted that the General tab is the only enabled option until the report name and focus are saved. The edit screen does not require a Save upon every action. On many areas of the setup, the application will auto-save the action just completed. In areas where it makes sense, a Save button is provided. An alert ( Report saved ) slides down anytime the report is saved on any tab. Information and help is provided on many fields and critical areas to help explain their purpose and provide guidance to completion. GENERAL TAB The General tab is the starting point to create a new report. The name, description and category will show up on the report as well as the management page where all reports are listed. The Report Focus is a very important setting for every report. This is a list of database tables which have been selected by an Administrator as top level (primary), starting points for data selection. As a report administrator, you can experiment with different report focuses and see how this affects

17 the set up process and final report. A good example of a Report Focus selection might be a report wherein the administrator wants a report of all accounts grouped by User, Branch and Region. In this scenario, the best Report Focus is Region because it is the outermost and largest grouping that will be shown on the final report. All data columns can be arrived at during setup by starting at the Region. The Owner of a new report is by default, the current user. As we ll see on the Sharing tab, reports can be shared or restricted, but the owner (as well as an Administrators) will always be able to view and edit any report. The Report Type refers to the style of resulting data grid and was put in place to accommodate integration with Resource One. Three options are available: Report this is the standard output to be viewed within CRW List this type must not include any user editable filters, summaries or charts. When this type is selected and CRW is integrated with R1, this list will appear on the R1 menu Both - The images are optional drop down selectors for assigning company logos and report images to pre-defined areas of the final report. Images are selected here from a library of uploaded images set up beforehand (see Image Management). SHARING TAB An administrator or report owner can grant others access to view and/or edit their reports. The sharing tab allows the user to share with other security groups or individual users. The leftmost checkbox is a View permission whereas the Edit permission is an additional checkbox. Export is not used at this time. COLUMN SELECTION TAB The Columns tab is where the columns for tabular data in the final report are selected. The list of columns is shown in a table as illustrated below. The administrator may edit, clone, delete or adjust the order of columns directly in the columns list.

18 STANDARD COLUMNS These are columns whose data will be derived from columns defined in the schema. This includes columns, virtual columns and extension columns. Column selector The column selector is shaded area at the top of the editor pop up window. Starting at the report focus table (in this case regions table), the user must select a database table column to use as a data source for this report column. The user may select a field or another linked data table. Selecting a field will end the selection process, whereas selecting another table will trigger another drop down to appear containing new fields and linked tables to choose from. Only when the user has selected an actual table field, does the selection process finish.

19 Label The header text to display on this report column. Default value A default value to be used in the event that there is a null value for this database column on any particular row. Column width The width of this column in inches on the printed report Algebraic identifier Optional, must be s SQL safe alphanumeric string to identify this column in other areas of the report setup such as calculated columns. It is a pointer. CALCULATED COLUMNS These are report columns whose value will be calculated with options to reference other columns within the report. Label The header text to display on this report column. Equation The equation to use to calculate the value of the column at each report row. Hover over the information icon for a full set of operations and rules available. Data type The basic data type for this field, used to render the report rows in a readable fashion. Column width The width of this column in inches on the printed report Algebraic identifier Optional, must be s SQL safe alphanumeric string to identify this column in other areas of the report setup such as calculated columns. It is a pointer. TABLE RELATIONSHIPS TAB On this tab, the administrator is presented with a tree of all of the tables that will be used for the current query. By selecting columns (on the Column Selection tab), the user specified that certain tables would need to be joined into the query. This UI allows the admin to specify that certain tables

20 are optional. This means that a LEFT JOIN would be created for the table. Simply select whether the table is Required or Optional and it is automatically saved. CONDITIONALS TAB Conditionals are an advanced feature that may be used in conjunction with filters (see Filters Tab). Think of conditionals as a grouping on/off switch for filters. A conditional may be tied to one or more filters. Consider the following: This conditional will be used with a couple different filters. When the report is run, the end-user will be presented with a dropdown labeled Account Type. They will be able to select either Commercial or Retail and upon selection will be presented with true filters which are tied directly to this conditional during filter setup.

21 Here, it is assumed that the report admin will set up two filters on contact type which will use this conditional. With this same functionality, the Commercial/Retail conditional could be associated with any number of specific query filters that further define what a Commercial or Retail record Is The identifier is an alias that must be unique to this filter. It is used to identify this filter when this report is set up as a sub-report within a union report (Discussed below). FILTRATION TAB The filters tab is where the report administrator can: Set up constraints on the query that will be used to return report data Set up constraint selectors that will be presented to the end-user when the report is run. The filter tab displays a hierarchical tree of existing filters and a summary of what each filter does. When the report is set up for the first time, there will only be a root node titled AND. As seen below, this node represents a logical grouping of conditions that must all be true. The user can right click on the AND to toggle it to an OR operator, add a new filter or a new group of filters. Throughout the tree, a set of actions are available at each node and are accessible by right clicking the text or icon. Groups may be nested as many levels deep as necessary and individual filters may be dragged into other nodes. Right click edit will bring the filter editor box up.

22 Filter Editor: Column selector The column selector is the shaded area at the top of the editor pop up window. Starting at the report focus table (in this case regions table), the user must select a database table column to use as a data source for this filter. The user may select a field or another linked data table. Selecting a field will end the selection process, whereas selecting another table will trigger another drop down to appear containing new fields and linked tables to choose from. Only when the user has selected an actual table field, does the selection process finish. Comparison Type This toggles the setup between a comparison of the selected column and a value, or another column. By selecting Column as the comparison type, the user will then be able to select another field, so cross column conditions can be used as a condition to filter results. Comparison (Value comparison type) This section will change depending upon what field is selected in the column selector. The important piece of information is the data type of the selected field. The following comparisons are possible based upon what kind of data will be compared when filtering. o Strings The user may select (Contains, Starts With, Ends With, Is Empty, Is not Empty, Equals, Not Equals) which will trigger UI selection as follows:

23 Simply enter text to compare to the field selected in the shaded region above. o Strings The user may select (Is Null, Is Not Null) which will trigger UI selection as follows: This comparison does not require any additional values. o Strings The user may have the option to select (In List, Not In List) if CoreTrac has enabled this field to have checkbox enabled selection. Many fields such as Department, Region, District etc. have checkboxes enabled for more intuitive value selection. o Numerics (Integers, Decimals etc.) The user will have the option to select (Equals, Not Equals, Greater Than, Greater Than Or Equals, Less Than, Less Than Or Equals) which will trigger UI selection as follows: Simply enter a number to compare to the field selected in the shaded region above. Only numbers and decimal points are allowed. o Numerics (Integers, Decimals etc.) The user may select (Is Null, Is Not Null) which will trigger UI selection as follows: This comparison does not require any additional values.

24 o Dates and DateTime Provide a few different options for selecting date ranges to filter on. Note that the Comparison drop down disappears. It will reappear once the date type is selected because the comparison changes and is secondary to the date type information. Begin by selecting the date filtration type: Month-to-Date, Quarter-to-Date and Year-to-Date require no additional information. The date used in this type of filter is the date and time that the report is run. Q1-Q4 will filter on a particular quarter. An additional year selector is presented to identify which quarter to filter on. Custom Allows the user to select specific dates and times. The checkbox will toggle on/off whether the end-user will be able to specify the time component when the report is run. Friendly name This is the name that will be used on the summary list of filters as well as the filter criteria that the end-user sees when they run the report. Conditional Allows the report administrator to make this filter dependent upon satisfying a conditional (See conditionals). Select a conditional from the drop down and then set which value from the conditional should trigger this filter to be active (to the end-user). External key is prefixed with rw_ automatically. This is a mechanism by which a report can be passed filter values through the query string when being called directly from another application. Identifier An identifier is an alias that must be unique to this filter. It is used to identify this filter when this report is set up as a sub-report within a union report (Discussed below). Allow user to adjust this filter This determines whether this filter is shown to the end-user when the report is run. If this filter is a part of the query that should never vary, do not allow the user to see it. If this filter should be set at run-time such as Department or Account Status selection, check this box.

25 GROUPS/SUMMARIES TAB The groups and summaries tab is the place to set logical groups of the tabular report data, and also summaries of information within each group. This tab shows an automatically ordered list of groups and summaries contained within each group. Additionally, there is a Report Footer group that cannot be deleted. The groups are indented according to their relationship to the Report Focus. This visual organization of groups should follow the logic of how the final report should look and is a good indicator of whether you re on the right track when setting up this section. To add a group, click on the Add Group button and to edit a group click on the edit icon.

26 Group Editor First, select table to use for grouping. The application uses the familiar column selector. Any endpoint column can be selected, but only certain ones will make sense for a given report. This is where pre-planning for the final report and grouping summaries is very helpful. The Algebraic identifier is used to identify this group data point in a unique way, so that within child summaries, the value can be used during calculations. The user may also check the box to insert a page break before each item in this group. So in this example, each Branch would be a group, but would not have a page break before it. Summary Editor A summary is a calculated value that is added at the end of a group. There are two types of summaries available. Group Summary This is a simple calculated value of a database column. Possible operations for this type are Average, Count, Sum, Min and Max. An example of this might be account balance sums for all accounts in a branch. The summaries are shown as line counts, sums etc. at the end of the parent group after the group tabular data. Assign an Algebraic Identifier so that this summary can be referenced from within calculated summaries (the next type of summary to be discussed).

27 Calculated Summary This type of summary allows for more complex operations and most importantly allows the administrator to create a summary that references other summaries by algebraic identifier. Basic syntax and order of operations apply, and a list of mathematical operations is available by hovering over the information icon next to the Equation text area. The Data type is used for report output display formatting. The Algebraic Identifier is an alias back to this summary. This may potentially be used by other summaries and/or charting since summaries can be used as chart axes.

28 Chart Editor Charts are used to display visual representations of the data, potentially including column and summary data. The system is left open and flexible with only a few logical limitations described below. Pie Charts 1. Label Column / Value Column A combo box with the following options a. Columns that have an algebraic identifier set (Column data will be used) b. Groups below the current level with an algebraic identifier set (Group name will be used) c. Summaries at the current level or below with an algebraic identifier set (Summary value will be used) d. Free form text the user may simply set a fixed label. 2. Caption The chart title. 3. Line Break Breaks the chart onto its own page.

29 Line/Bar Charts 1. Series Source The third dimension of data, this sets the source for the group of lines or bars. a. Columns that have an algebraic identifier set (Column data will be used) b. Groups below the current level with an algebraic identifier set (Group name will be used) c. Summaries at the current level or below with an algebraic identifier set (Summary value will be used) d. Free form text the user may simply set a fixed label. 2. X-Axis/Y-Axis The Same data sources are available in these combo boxes. Labels are optional additional text for the graph. 3. Caption The chart title. 4. Line Break Breaks the chart onto its own page.

30 Charts in the Report Footer There are a couple special rules on setting up charts in the report footer. Selectable data sources (via combo boxes) are limited by some logic. 1. Pie charts a. Label/Value selection does not allow for selection below the first group level 2. Line/Bar charts a. Series source and both axes do not allow for selection below the first group level

31 EDITING A UNION REPORT A Union report is a type where one or more other CRW reports are used as sub report datasets to create a union dataset. Special care must be taken to ensure that all subreport columns are the same number and are the same types of data. Additionally, friendly names of columns that will be unioned, must be the same. GENERAL TAB The only important difference here is that the report focus is no longer available. The union report relies completely upon the subreports for data context. REPORT SELECTION This is where the user selects which reports will be used for data. CRW will analyze the reports as they are added to determine if there are any conflicts with the different sub report datasets. COLUMN SELECTION TAB This is the same as the column selection for regular reports, except that the column chain selector is now only populated with the column friendly names from all of the sub reports. The column selection is essentially a meta column selection. Calculated columns function exactly the same as in regular reports, with algebraic identifiers referring to other columns on the union level, no the sub report level. CONDITIONALS TAB In the union report context, this tab is a means to set up conditional criteria (see regular reports) that will be passed down to the subreports. The mechanism for doing this are the identifiers that can be saved within subreport conditional editing. In this example, there is one conditional in a subreport with an identifier c1. The UI here notifies the user that the conditional has not be set up here on the union level and the report will not run. Upon editing this conditional, the administrator sets this conditional up on the union level, gives it a friendly name, optionally selects a default value and toggles whether or not the end user may see this conditional at all.

32 FILTRATION TAB The filtration setup for Union reports follows along with the conditional system of passing through values to subreports at runtime. Any subreport with a filter that has an identifier, will be shown in the union report filter grid like below. Click on the edit icon to set each filter. The edit filter dialog allows the administrator to set the filter default values, give it a new friendly name and toggle whether or not the end user can adjust the filter. Note that the type of comparison, database field etc. are not settable here. That is done on the sub report level. The purpose here is to simply set values to pass down to sub reports at runtime.

33 GROUPS/SUMMARIES TAB The group and summary functionality is much the same as with regular reports. The only difference is that column selection within the group setup is restricted to columns (friendly names) on the union report level. This is the same list available in the Column Selection process.

34 VIEWING REPORTS The user may view a list of available reports by going to the List Reports page (domain\listreports.aspx). Click on the down arrow to pop open a report parameter form that is used to provide the report engine with the necessary input criteria to run. An example of the View Report parameter form can be seen below. Each of the filters that the report administrator set as Changeable by the end-user, is presented here. In addition, any Conditionals that are tied to filters are presented first, at the top of the form and separated with a horizontal line.

35 Toggling the conditional will also change the filters presented in the rest of the form as the conditional determines which filters are necessary. The filter form is very similar to the Administrator form except that filters which are Lists now have a Manage List button which pops up a checkbox list for easier selection and management. Everything else is the same. When all criteria have been set, select Run this report button to see the final report.