Watch this Ask the Expert session to learn how to use SAS Visual Investigator to identify suspicious anomalies in data.    Watch the Webinar   You will learn: About SAS Visual Investigator and its core concepts. How to create row-level scenarios to survey data by transaction. How to create aggregation scenarios to survey data at an aggregate level.   The questions from the Q&A segment held at the end of the webinar are listed below and the slides from the webinar are attached.   Q&A Which Viya licensing package includes this tool? i.e. VA, Viya, etc. SAS Visual Investigator is now a platform level product that should be included in all Viya installations. For licensing details, please reach out to your account executive.   What is the process of validating or testing a newly created scenario to ensure its effectiveness? SAS Visual Investigator offers the capability of testing your scenario in advance. There’s a button built into the scenario administration screen that allows the administrator to test the scenario to ensure that it’s built correctly, and it effectively captures the desired behavior. In the test results tab, the administrator will be shown a summary of how many hits were generated by their scenario.   Would you please quickly show us or explain the data step level investigation? Within the Alert Flow, a DATA step scenario can be created using the same drop-down menu as the other primary and secondary scenarios.   Once inside the scenario page, SAS DATA step code can be entered within the DATA Step Code tab. The code editor provides the following features: syntax highlighting autocomplete functionality a code-folding toggle icon that enables you to collapse and expand each DATA step in the code editor. a pop-up menu that provides cut, copy, paste, undo, and redo operations. To access this menu, right-click in the code editor. support for undo and redo keyboard shortcuts. Please see below for a code example. Stay tuned for an upcoming SAS Communities blog post diving deeper into DATA step scenarios.   How customizable are the scenarios in SAS Visual Investigator? As demonstrated in the webinar, the scenario authoring feature of SAS Visual Investigator is incredibly powerful. It allows the organization to capture anomalies within their data on multiple levels using a low code UI. Additionally, with the use of DATA Step scenarios, the administrator can design the most flexible scenario yet, using SAS DATA Step code and macro language.   Aside from numeric values, is it possible to search for text that may be in a field of the data set? Yes, in addition to capturing anomaly within the numeric fields, it is possible to capture information embedded in character strings as well.     Recommended Resources SAS® Visual Investigator: Analysis and Investigation Building an Interface with SAS® Visual Investigator SAS® Visual Investigator for Developers SAS Visual Investigator: It’s Not JUST for Fraud Please see additional resources in the attached slide deck.   Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q&A, slides and recordings from other SAS Ask the Expert webinars.   ... View more

One of the most powerful features of SAS Visual Investigator is its scenario authoring capability. It allows administrators to build scenarios using organization-specific business rules to detect anomalies, potentially stopping illicit activities in their tracks.   The different types of scenarios supported by SAS Visual Investigator are as follows:   Record-level Scenario: Evaluates the data by individual records Aggregation Scenario: Evaluates the data at an aggregated level DATA Step Scenario: Uses SAS DATA step code and SAS macro language to create a truly bespoke scenario Summary scenario: Uses the scenario-fired events generated by primary scenarios as input data and applies rules to that data to generate a final outcome.   Once an alert flow has been created and the desired data sources have been loaded, the new scenario dropdown menu on the flow page can be used to create a new scenario:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   However, sometimes you may find that the Aggregation scenario menu option is grayed out.     This is because the appropriate relationship hasn’t been configured between the relevant entities. This post aims to help you navigate this issue with a worked example.   Example Scenario for Insurance Fraud   The desired behavior that we wish to capture is a situation where multiple insurance claims are filed against a single insurance policy. In the network diagram below, policy is represented by the blue document icon and claim is represented by the orange document icon. As illustrated, multiple claims are attached to the single policy. This pattern of losses might suggest that the policy holder is intentionally exploiting the system—a behavior worth further investigation.     Prerequisites   In order to build this particular scenario, three pre-requisites must be met:   The appropriate source table must be loaded. In this case, the source table is the table holding the insurance claims data. Within this table, there must be an association between claims and policies such that we can group by the common policy number and count the number of claims filed against it. See below for an example of the data.   Table 1: Mock auto claim data   Claim ID Policy ID … 1001 100 … 1002 200 … 1003 300 … 1004 300 … 1005 300 … 1006 400 …   In the above example, there are three claims filed against the policy with the Policy ID of 300. This is the behavior we wish to flag.   This data source can be added to the alert flow by simply navigating to the Data Sources section of the flow page and using the Add data sources button.     There must be a configured and reindexed relationship between the actionable entity and the source data. As illustrated in the previous prerequisite, there is a clear data relationship between claim and policy in the source table auto_claim. It is evident that this relationship is many-to-one, as in multiple claim records could share a common Policy ID value. This relationship must be correctly configured in SAS Visual Investigator before we can proceed with building an aggregation scenario. Within SAS Visual Investigator’s relationship builder window, the relationship should be configured as such:   “From” entity: Auto Policy Cardinality: One-to-Many “To” entity: Auto Claim Bridge table type: (none) Join condition: Policy Id (“Auto Policy” field) = Policy Id (“Auto Claim” field)     Two things to note. Firstly, for SAS Visual Investigator, the order of the pairing matters. A relationship that’s defined as from policy (one) to claims (many) is not equivalent to a relationship that’s defined as from claims (many) to policy (one). The “From” entity in a relationship will later become the actionable entity in our scenario.   Second thing to note is that no additional bridge table is necessary in this relationship definition, as there’s already a claim-to-policy association in the auto_claim table.   Lastly, as a best practice, always reindex your relationships and entities after modification.   The correct actionable entity must be defined. It might be intuitive to assume that since we have loaded the auto claim table, then the actionable entity must be auto claim. This is incorrect. In this case, the actionable entity is actually the auto policies that we are aggregating on.     Configuring the scenario   Once the three prerequisites are met, the building of the scenario can commence. Under the Details section, define Date and time field, Lookback unit, and Group by fields. We want to group by the ID associated with our actionable entity—Policy Id—and use claim incident date as the Date and time field. The lookback unit can be defined as month-to-date or day.     Navigate to the Aggregations tab and configure it as follows to allow us to count the number of claims filed against a policy over a lookback period of six months.   Column to aggregate: claim_id Metric: count Lookback (Month-to-date): 6 Offset: 0     Next, navigate to the Rules tab and define the condition as:   If the aggregation is greater than 1, then assign a numerical score.     The scenario configuration is now complete. As a best practice, always test the flow after creating or updating a scenario. The Test Results tab can shed light on the efficacy of your scenario. Use it to fine tune your scenario base on your organization’s unique needs.     Conclusion   The most important takeaways of this post are:   A relationship must be defined between the actionable entity and the data source before SAS Visual Investigator will give you the option to create an aggregation scenario. In the scenario, the “from” entity of the relationship is the intended actionable entity. (Example: Auto Policies) In the scenario, the “to” entity of the relationship is intended to be the data source. (Example: Auto Claims) The relationship must be one-to-many (Example: One policy to many claims) or one-to-one (rare, but possible).   I hope this worked example helped you navigate the finer intricacies of designing and building an aggregation scenario in SAS Visual Investigator.   Read more   About Configuring Relationships for Flows and Scenarios   Scenarios in SAS Visual Investigator   SAS Visual Investigator and Scenario Administrator   Using a Lookback in Scenarios: Lookback Basics     Find more articles from SAS Global Enablement and Learning here. ... View more

This post is written in collaboration with SAS R&D, drawing from the SAS R&D article VI Page Layout Guidelines by Peter Eastwood, Distinguished User Experience Designer.   One of the most powerful features of SAS Visual Investigator is Page Builder—a no-code graphical interface that allows administrators to build stylish and functional User Interface pages through drag-and-drop. The administrators can decide on the data elements, as well as how that data is structurally presented to the end users. To best leverage the vast capabilities of Page Builder, we are creating a multi-part series on page building best practices.   This post is Part I of this series and it centers around layout elements—columns, group boxes, and tabs—and how best to use these elements to build a page that is intuitive, consistent, and user friendly.   Overview   Page Builder is a graphical interface that’s integrated into SAS Visual Investigator, allowing administrators of SAS Visual Investigator to create page templates using the application’s default elements. A typical page template includes elements like controls, charts, and layouts.   From the Manage Investigate and Search interface, also known as the SAS Visual Investigator Administrator UI, Page Builder can be accessed through either the Data Objects tab or the Pages tab. Within a new page template, a list of out-of-the-box controls can be found under the Controls tab. The administrator can build a new page template by dragging and dropping the desired controls onto the canvas. These controls are typically linked to a data source. Once created, the page templates are rendered as user-facing pages, where the content of the pages are determined by the template’s elements and populated from the data source.   This post focuses on best practices with using layouts, which is a set of controls used to organize the layout of a page.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Group Boxes   A group box is a way to group controls and data elements together based on some commonality. They can be given a title to provide more context and reasoning behind the grouping. For example, data elements such as Claim ID, Claim Type, and Claim Status can be organized into one group box titled “Claim Information”.   Recommendation 1: Instead of populating a page with loose controls, use group boxes to organize them. This organization helps to create a clear, logical structure, making the UI more intuitive to navigate.       Recommendation 2: Deconstruct long group boxes into several smaller ones. This reduces empty space on the page. This also makes the content more digestible by allowing users to focus on smaller sections rather than being overwhelmed by one lengthy block of information.       Recommendation 3: Avoid placing multiple columns within a single group box. Not only does this contribute to a cluttered layout, but it can also result in overlapping elements and misalignment when the UI is viewed on different screen sizes.       Recommendation 4: Avoid wide group boxes with narrow lists of attributes. Instead, make group boxes as narrow as possible to fit the content of the box. This makes the page more compact and efficient.       If there are only two or three columns, blank columns can be included to ensure that the existing columns are not too wide. To do this, click on New column in the Columns pane located on the right of the canvas. The arrow buttons can be used to move the new blank columns to the right.     Recommendation 5: Align the bottom borders of group boxes for a cleaner layout.       By default, the height of a group box is automatically determined by its content unless a height has been specified under the Height section of the Columns pane. To ensure that the bottom borders of the group boxes are aligned, check the Fill available space radio button or specify a value under Fix height to.     Tabs   Tabs are another way to organize page elements. In SAS Visual Investigator, there are two types of tabs: top-level tabs and tab controls. Tab controls can be found under Controls > Layout > Tabs, whereas top-level tabs are configured under Page properties.     Recommendation 6: Use top-level tabs for high-level categorization of the page instead of tab controls. Reserve tab controls for low-level categorization within individual sections.     Recommendation 7: In general, avoid nested tabs. If nested tabs are unavoidable, use Lightweight tab style for the inner tabs.       To set the inner tabs to light weight, check the Lightweight tab style checkbox within the Tabs pane.     Next   I hope this post has been helpful to you in your journey of building an efficient, intuitive, and user-friendly page. Stay tuned for the next post in this series where I will dive deeper into SAS Visual Investigator page building best practices.   Learn More   Streamlining Reporting with Print Templates in SAS Visual Investigator     Find more articles from SAS Global Enablement and Learning here. ... View more

This post is adapted from the SAS R&D article Have you tried increasing your chunk size? written by Liam Macpherson, Senior Software Developer at SAS.   In SAS Visual Investigator, data needs to be indexed before they are searchable by end users. Re-indexing is often necessary when the configuration of existing objects (entities, relationships, and transactions) have been updated. Thus, the performance of the indexer is vital.   Under global properties, the Indexer Partition option allows SAS Visual Investigator administrators to optimize parallel data processing during indexing. To enable this, data is divided into equal-sized segments, known as partitions. Administrators control how many partitions are processed simultaneously by configuring the system to read, enrich, and write data in chunks, starting from the beginning of a partition and working through to the end.   There are three key settings that influence the size of the partitions and chunks:   Partition multiplier Partition size Chunk size   This post focuses on chunk size, both its usage and its limitations. Additionally, this post explores how adjusting the chunk size can enhance indexing performance, ultimately improving data accessibility and helping SAS Visual Investigator users make faster and more informed decisions.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Introduction   Indexing is often seen as a black box: data in, search results out. This means when something breaks or doesn't perform as expected, often there's not a great deal of understanding about why or what can be done to resolve it. When we want to dig deeper on one particular mechanism, we are often opening up multiple black boxes nested within one another.   We have taken steps to improve output and clarity. The Job Monitor gives us indexer metrics which provide a peek into the first box, to see how long things spent in the various nested black boxes.     Adding tuning settings directly to the SAS Visual Investigator’s Administrator User Interface (Manage Investigate and Search) allows some tweaking based on previous experiences or guidance from experts. The indexer team executed some formal testing making use of these tuning settings and have analyzed the results here.   This testing was carried out as verification of a fix for particular customer, they saw results which far exceeded our expectations—an original throughput of 62,500 records/minute increased to 1.2 million records/minute. This is an 1820% increase in throughput. In our testing, we saw marked increases between the pre-fix version and post-fix version.   These things help but more testing and learning are required, as well as making even more parts of the process visible to end users.   Terminology   Search Index: An external piece of software which stores data in such a way that means it can be simply accessed and searched. This in SAS Visual Investigator has been Elasticsearch (prior to version 10.8) and OpenSearch (post version 10.8).   Indexing: This is the process of taking external data, enriching it and loading it into the search index.   Bulk Indexing: This is taking all the data stored for a given data object and loading it all into the search index.   Incremental Indexing: This takes a subset of the data and loads it into the search index based on the date at which it was most recently updated. The intent is to index smaller volumes of data more frequently.   Chunk Size: The smallest unit of processing. A chunk of data is read, enriched, and indexed as a single unit. You must consider any memory implications when setting the chunk size as different object types have different memory requirements.   Considerations   Further research is always needed as the indexers are constantly evolving and improving, while organization-specific environments and use cases are nuanced and complex. These are the two main limitations to any testing of the indexer. It is fixed in time and tied to several factors outside of our control.   At time of writing, the indexer is at version 3.23.28, the testing which was carried out was against version 1.6.39 for 10.8 Hot Fix 6. It was carried out as means of verifying a proposed fix the indexer was putting forward. We extended it to cover more data stores and tweaked it to give us as full a picture as we could get while still getting confirmation that the customer's indexing was going to perform as well it could in Hot Fix 6.   Many releases have followed, aspects of the indexer have changed but this testing and result set can act as a point of comparison for just some of the variable aspects which customers have control over. We also hope that it'll guide some testing we want to carry out in the future.   We are not testing:   Relationships Transactions Customer representative data or deployments The tweaking of any other settings—everything else is left as default The latest version of the indexer which may contain several performance improvements, which can affect the benefit of tweaking any particular settings.   Testing Methodology   The testing was repeated against all our currently supported data stores, making for simple comparison of results. These tests analyze the effect of changing the chunk size with various data loads. We looked at two questions for each test case:   Did the indexing complete? How long did the indexing take to complete?   Our variable factors were:   Chunk size: set intervals of 1000, 5000, 7500 and 10,000. Target records: set intervals of 10,000, 100,000, 1,000,000 and 2,000,000. Data stores: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL and Teradata.   All tests were carried out against tables with similar data that were partially randomly generated but in the format of:   Two primary key columns which were VARCHARs. A single TIMESTAMP column.   An example of this can be seen below.     An external entity was created in SAS Visual Investigator backed by this table. We also did a baseline full index of the entire table (always 2,000,000 records in these tests) which follows a slightly different path and is therefore useful for giving us a different comparison of full indexing versus incremental.   Testing was carried out against an development machine with out-of-the-box configuration. The machines have 32GB of RAM and 4 CPUs.   Results   The result section is split by data store:   IBM DB2 Incremental     Bulk     Microsoft SQL Server Incremental     Bulk     MySQL Incremental     Bulk     Oracle Incremental     Bulk      PostgreSQL Incremental     Bulk      Teradata Incremental     Bulk     Analysis   This section looks at some of the results with a view to make use of them to guide tuning, or as a point of comparison for other sets of results going forward.   Incremental vs Bulk   This is the expected behavior of incremental indexing versus bulk. The mechanisms through which we split the workload of records to be read, processed and written to the search index introduces extra overhead. Therefore, comparisons between the two are intended to show that chunk size has an effect on both bulk and incremental indexing, rather than show how much quicker bulk indexing is than incremental indexing.   It is worth noting that bulk indexing can be viewed as the simplest method of indexing, and therefore an ideal to be aimed for. Which is why seeing incremental indexing approaching bulk indexing times by lowering the chunk size is an excellent indicator that systems can indeed benefit from tuning.   Data Stores   The first thing which jumps out are the stark differences between the different data stores. Teradata takes around 105 minutes with a chunk size of 5000, PostgreSQL takes under 10 minutes to process the same volume of records with the same chunk size. This speaks more to the differences between data stores and the hardware which is backing them than any reflection of how the indexer interacts with different data stores. There are some specific limitations which are forced upon the indexer's processes from the data vendors, but the main reasoning for the huge discrepancy is just that they are different data stores which handle queries differently, have different hardware hosting them. This should not be read as "don't bother tuning if you are using Teradata/MySQL/Microsoft SQL Server". It may just be the chunk size should not be the first port of call for tuning.   Chunk Size Recommendation   Over the years we have changed the default chunk size. Generally speaking, we want it increased to the point we are utilizing as much of the resources available as we can. From this we want to maximize the usage of the indexer's memory without overloading it, we want to be reading as much from the database and writing as much as we can, as quickly as we can. Sometimes one of these resources will provide pushback or cause a bottleneck. This explains the diminishing returns in throughput we see in IBM DB2, Oracle and PostgreSQL results when the chunk size increased from 1000 to 5000.   This resourcing issue also explains the failures we saw in the upper volume chunk size Oracle tests, we were simply reading too much into the indexer's memory. More can be understood about the mechanisms going on in parallel by looking at the workers which operate as part of indexing.   Further Testing   Further testing is always needed. Automation of this testing will allow for even simpler and more frequent comparisons to be drawn as the indexer improves version to version.   Areas requiring further testing based on the discoveries here are:   Replicating these tests with more representative environments. The hypothesis being we'd see even bigger improvements or at least see the results scale. Identify resourcing issues preventing chunk size from having an effect in SQL Server/Teradata Test the effects of the other tunable components of the indexer: Partition Multiplier Partition Size Worker pools Combinations of these settings together   It’s worth noting that the above settings are well documented in the indexer performance tuning chapter of the SAS Visual Investigator: Administrator’s Guide.     Find more articles from SAS Global Enablement and Learning here. ... View more

SAS Visual Investigator, running on the robust SAS Viya environment, is a cloud-ready, highly customizable investigation and incident management solution. It allows investigators to manage the end-to-end lifecycle of an investigation. Offering comprehensive features such as alert management, advanced search capabilities and intuitive data visualization, it caters to a diverse array of industries such as insurance fraud and anti-money laundering (AML).   Given the diverse reporting needs across industries and organizations, SAS Visual Investigator offers a functionality called Print Templates. This functionality enables SAS Visual Investigator administrators to define how an entity’s data is presented when printed, allowing for the precise tailoring of output reports to meet each organization’s specific reporting requirements.   Print Templates can be configured for both internal and external entities, encompassing a wide range of data objects internal and external to the SAS Visual Investigator solution. Multiple Print Templates can be defined for each entity type.   Like designing custom pages in SAS Visual Investigator, defining new Print Templates is simple and does not require any programming knowledge. SAS Visual Investigator administrators can design, create and deploy custom Print Templates directly from the SAS Visual Investigator user interface. In this post, we will explore the Print Template feature in detail, covering everything from prerequisites to template creation, access and management. In a step-by-step walkthrough, we will show you how to build the example Print Template below in SAS Visual Investigator using fictitious insurance data.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Pre-requisite   Once the Print Templates have been created for a given entity, SAS Visual Investigator users can print entity data in the structure and format specified by the template. They can perform the following actions:   Print: Print the structured information as a PDF or send it directly to the printer. Attach: Attach the structured information as a PDF to the entity page.   To enable the above capabilities, SAS Visual Investigator administrators must first configure the relevant entity types to support printing and attachments. This is achieved through customizing the toolbar on the entity page to include the necessary buttons.   Steps to Configure Entity Toolbar:   Navigate to SAS Visual Investigator – Manage Investigate and Search. Select the entity type: Click on Data Objects, then select Entities to view all available entity types. Double-click on the entity type of interest. For this example, we’ll select the Auto Policy entity.     Customize the toolbar: Click on Pages and Toolbar to find the available pages and toolbar items. In the Toolbar Items section, click the New Toolbar Item dropdown menu. Select Attachments, followed by Print.       Save the configuration.   With these configurations in place, SAS Visual Investigator users will be able to leverage any existing Print Templates for printing and attachment.   Create a Custom Print Template   Page Designer empowers SAS Visual Investigator administrators to create custom Print Templates without the need to write code or manually edit configuration files. It supports the addition of various content types, including:   Static content Entity data fields Entity labels Relational data from child or related objects User and date information Document classification marks Comment boxes for user input before printing Embellishments such as hyperlinks and images       Prior to walking through a hands-on example, we will provide an overview of Page Designer and its capabilities:   Choose Build Mode: Choose between Design Mode and HTML Mode. Design Mode offers a no-code approach to building Print Templates while HTML Mode allows the administrator to insert custom HTML code. Any work completed in Design Mode can be further refined in HTML Mode. Build by section: In Design Mode, choose the section of the print template to edit, whether it’s body, header, footer or watermark. Add Basic Content: In Design Mode, the administrator can add static content by typing directly in the provided canvas. Insert Advanced Content: In Design Mode, use the Insert Label, Insert Value, and Insert Component dropdown menus to introduce more complex elements. Enhance and Embellish: Leverage the toolbar in Design Mode to add objects such as bullet lists, numbered lists, hyperlinks, images and tables to the template. Customize Appearances: In Design Mode, use the toolbar options to change font styles, alignment, sizing, and colors to match the organization’s reporting requirements. Configure PDF Settings: Configure PDF properties to ensure compliance to organizational reporting requirements. Save the Print Template   Example: Creating a Print Template for Automobile Insurance Policy   Now we will walk through the creation of a custom Print Template for the automobile insurance policy entity.   Access the Print Templates page: From SAS Visual Investigator – Manage Investigate and Search, click on Pages, followed by Print Templates. This is where all the configured Print Templates can be found. Create a New Print Template: Click on New Print Template to create a new template.     Define Key Template Properties: From the Data Source dropdown list, choose the relevant entity type. In this example, we'll choose Auto Policy. Provide a name for the template in the Name field. Select SAS Visual Investigator as the Solution. Click OK to proceed.       Now we are ready to use Page Designer to create the new custom template. We will design the template section by section.   Header & Footer   When creating a Print Template, it’s essential to structure the header and footer effectively. To configure the header:   Element Spacing: Under the Header tab, a table-like object is included by default to ensure consistent spacing between elements, the outline of which won’t appear in the final printout. Adding Static Content: In the first cell, add the text string “Fictitious Insurance Company”. In the second cell, enter “Policy Number:” to label the policy number. Since policy number is an entity data field, this label could also be achieved using the Insert Label dropdown menu. More on this later. Inserting Dynamic Data: To dynamically display the actual policy number in the printout, we need to insert a token for the data. Click on Insert Value to open a dropdown menu of available data fields linked to the policy entity. For this example, select Number, which represents the policy number.     Adding Current Data and Time: In the third cell, we want to show the date and time at which the printout is created. This is another dynamic element. Click on Insert Component and select Current Date/Time from the dropdown, then choose Date and Time to add this component.     To configure the footer:   Adding Dynamic User Information: In the footer, we want to display the name of the user who is viewing and printing the entity in question. To achieve this, navigate to the Footer tab and click on Insert Component. Select User Details from the dropdown, followed by User Name.   Body   To effectively present policy data within the body of a Print Template, we will leverage the table and grid functionalities offered by Page Designer.   Display Policy Data in a Table Using the Table Wizard to create the table: To display data in a tabular format, start by selecting the Table Wizard found in the upper right corner of the toolbar. This wizard allows us to specify the desired dimensions of the new table.     Applying Data Labels: In the first column of the table, we want to apply labels to identify the data fields. This is achieved by using the Insert Label dropdown menu, within which all available data fields associated with the given entity type can be found. These tokenized values will automatically populate with the correct data labels when the entity is printed.     Display Data Values: In the second column of the table, we want to display the actual data values associated with the entity data fields. This is done by selecting the Insert Value dropdown menu and choosing the appropriate data fields, ensuring each value aligns correctly with its corresponding label. These data values will be dynamically populated during the printing process.     Adding Relational Data   A powerful feature of the Print Templates is that it allows for the insertion of relational data. In Page Designer, this is known as Repeating Data. It’s surfaced from relationships and traversals, or in other words, from child objects and related objects. In our example, we want to list all the insurance claims that have been filed against a given policy.   To insert Repeating Data:   Select Insert Component dropdown menu, choose Repeating Data.     In the new menu box, select the relevant Data Source from the dropdown menu. Under Relationships, child objects such as claims can be found. Under Traversals, related objects such as alerts can be found. For this example, we will select Auto Claim – Auto Policy.     Define the Sort field and Sort order as desired. The resulting Repeating Data grid will look like the below.       Configure PDF Layout for Optimal Display   Since the Repeating Data grid grows horizontally, one might wish to rotate the page from Portrait to Landscape for better readability.   To achieve this:   Click on Properties in the top menu bar. Change the layout from Portrait (default) to Landscape. Click on the Allow user to change PDF settings button if you wish to allow users to make adjustment to the PDF properties during the printing process. Other document properties such as page margins, title and author can be adjusted here as well.     HTML Mode   For those who prefer more control over their template design, SAS Visual Investigator offers a HTML mode. In this mode, any standard HTML elements can be added.   Click on HTML on the toolbar to switch to HTML mode. Note that the design we created in Design Mode has been converted to HTML and can be edited.     By utilizing both HTML and Design modes, highly customized and professional Print Templates can be created to meet the specific reporting needs of the organization.   Print Templates - Access and Usage   Once a Print Template has been created for an entity, SAS Visual Investigator users can easily access and utilize it through the toolbar’s Print button on the entity page.   Under SAS Visual Investigator – Investigate and Search Data, pull up the relevant entity. In the example below, an Auto Policy has been opened. Click on the Print button in the toolbar.     Select Print to PDF to see a preview of the PDF, populated with the entity and session specific information. If there are multiple templates associated with the entity type, they will appear on the left panel for user selection. Click Next to proceed.     If the administrator had the Allow user to change PDF settings button checked during the template creation process, users will see the following screen and be prompted to make edits to the PDF properties. Click on Print to PDF to print the entity data to a PDF file following the structure and format set by the Print Template.     Here’s the final PDF document showing the different components we covered in this example:   Static content Entity data fields Entity labels Relational data from child or related objects User and date information     Summary   In this post, we explored the Print Template feature in detail, covering everything from prerequisites to template creation, access and management.   The key takeaways are:   Print Templates enable SAS Visual Investigator administrators to define how an entity is displayed when printed, offering control over the presentation of the printout. Print Templates can be created for both internal and external entities. Multiple Print Templates can be created for a given entity. Print Templates will only be available to SAS Visual Investigator users if both the Print and Attachment buttons are enabled for the given entity type. Created using Page Designer, creating a Print Template is fast, easy and does not require programming knowledge. Static, dynamic and relational content can all be added to the Print Template.   Learn More   Scenarios in SAS Visual Investigator Workflows in SAS Visual Investigator Getting started with the REST APIs of Visual Investigator     Find more articles from SAS Global Enablement and Learning here. ... View more