# Report Access Logging ## Table of Contents * [Overview](#overview) * [What Gets Logged](#what-gets-logged) * [How Logging Works](#how-logging-works) * [Using Access Logs for Auditing](#using-access-logs-for-auditing) * [Using Access Logs for Usage Analytics](#using-access-logs-for-usage-analytics) * [Multi-Tenancy and Data Isolation](#multi-tenancy-and-data-isolation) * [Common Scenarios](#common-scenarios) * [Troubleshooting](#troubleshooting) ## Overview Report Access Logging is an automatic audit trail that records every time a user opens a report in OtisEd.Nimble. The system silently captures who accessed which report, when they accessed it, and what filter parameters were active at the time. This provides administrators and auditors with a complete, time-stamped record of report usage across the organization. Access logging runs in the background without any action required from the user. Reports are logged at the moment they are opened, so the audit trail reflects actual usage in real time. ## What Gets Logged Each access log entry captures the following information: * **User** — the identity of the user who opened the report. The system records the user automatically from the authenticated session, so the log is always tied to a specific account. * **Report** — the specific report that was accessed, identified by its unique ID within the system. * **Access Date and Time** — the exact date and time the report was opened, recorded using the server clock at the moment of access. * **Report Parameters** — any filter parameters that were active when the report was opened. This captures the context of the access, such as which school year, district, or school was selected, so the log shows not just that a report was viewed but what data the user was looking at. * **Tenant** — the organization (tenant) associated with the access. In a multi-tenant deployment, each log entry is scoped to the tenant of the user, keeping data from different organizations separate. Entries are written once at the time of access and are not modified afterward. This preserves the integrity of the audit record. ## How Logging Works Logging is automatic and transparent. When a user opens a report, the application records an entry in the background. Users do not see any indication that logging is occurring, and logging does not affect the time it takes to load a report. The log is append-only from the perspective of normal system operation. New entries are created each time a report is accessed. If a user opens the same report multiple times — even within the same session — each access produces a separate log entry. This means the log reflects the full history of interactions, not just whether a report was ever viewed. ## Using Access Logs for Auditing Access logs provide a reliable audit trail for report usage. Common audit uses include: **Verifying user activity.** You can confirm that a specific user opened a report on a given date. Because the log records the exact access time alongside the user identity, it can corroborate or refute claims about when data was reviewed. **Reviewing parameter context.** The log captures the filter parameters in effect when the report was opened. This means an auditor can see not only that a user accessed a report but also which subset of data — such as a specific school or academic year — was in view at that time. **Tracking access across date ranges.** Logs can be filtered by minimum and maximum access date to review all activity during a specific period. This is useful for periodic compliance reviews or after-the-fact investigation of access patterns during a particular timeframe. **Scoping to individual reports or users.** You can narrow the audit query to a single report (to see everyone who accessed it) or a single user (to see all reports that user has opened). This targeted lookup helps respond quickly to specific audit questions without wading through unrelated records. ## Using Access Logs for Usage Analytics Beyond formal auditing, access logs reveal how reports are actually being used across the organization. This information can guide decisions about which reports are valuable, which are rarely used, and what filter contexts are most common. **Frequency analysis.** By counting access log entries per report, administrators can identify which reports are accessed most often. Frequently accessed reports may benefit from priority maintenance, performance optimization, or promotion to a more visible position in the navigation. **User engagement patterns.** Reviewing logs by user shows which staff members are actively using the reporting system and which are not. This can inform training efforts or help administrators identify users who may need assistance getting value from available reports. **Parameter usage.** The parameters field in each log entry captures the filter context at access time. Reviewing common parameter values can reveal which schools, districts, or academic years are most frequently analyzed, helping administrators understand where attention is focused across the organization. **Time-based trends.** Comparing access counts across different date ranges reveals seasonal or event-driven patterns in report usage. For example, access to certain reports may spike during reporting deadlines or state assessment periods. ## Multi-Tenancy and Data Isolation OtisEd.Nimble supports multiple organizations (tenants) sharing the same platform. Report access logs are fully isolated by tenant. When a log entry is created, it is tagged with the tenant of the authenticated user, and log queries are automatically scoped to return only entries belonging to that tenant. This means: * Administrators from one organization cannot see access logs from another organization. * Reports and users from different tenants are tracked independently even if they happen to access reports with the same identifiers. * Data isolation is enforced at the database level, not just the UI level. ## Common Scenarios **Scenario: Confirming a user reviewed a report before a deadline.** An administrator needs to verify that a district coordinator opened the end-of-year summary report before the submission deadline. Using the access log, the administrator can filter by that user and the specific report, then check whether any entry falls before the deadline date and time. **Scenario: Identifying unused reports.** A system administrator wants to know which reports have not been accessed in the past six months in order to consider retiring or archiving them. By querying access logs with an access-date range and grouping by report, unused reports will appear with no entries during the period. **Scenario: Auditing access after a data incident.** Following a report of potential unauthorized data access, an administrator needs to see which reports a specific account opened and what filter parameters were active. The access log provides a full timeline of that user's activity, including the exact data context for each access. **Scenario: Tracking usage around a policy change.** After rolling out a new report, administrators want to measure adoption. By querying access logs for the new report and comparing entry counts week over week, they can see whether usage is growing, plateauing, or declining and adjust communication or training accordingly. ## Troubleshooting **A report access does not appear in the log.** Access logs are written at the time a report is opened via the application. If a report was accessed outside the normal application flow — for example, by direct API call without going through the reporting interface — a log entry may not have been generated. Confirm the report was opened through the standard report viewer. **Log entries show a different time than expected.** Access dates are recorded using the server clock at the moment of access. If the time appears offset, this may reflect a difference between the server's time zone and the user's local time zone. Verify that the server is configured for the correct time zone for your organization. **Cannot find log entries for a specific user or report.** Confirm that the correct user identifier and report identifier are being used in the query. User and report identifiers in the system are internal unique values, not display names. If you are filtering by identifier, verify the values match the actual records in the system. **Log entries are missing parameters.** The parameters field is optional. If a report was accessed without any active filter selections, or if the report does not use parameters, the parameters field on the log entry will be empty. This is expected behavior and does not indicate a logging failure. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://nimble.docs.otised.com/guides/report-access-logging.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.