You can build what your client wants, but you’ll have to go beyond the default Service Center dashboards and work directly with the platform logs.

1. Why Service Center only shows 7 days

The Service Center home dashboard (“Web screen views in the last 7 days”, “End-user accesses in the last 7 days”) is just a built‑in visualization on top of the platform log tables. It’s intentionally limited to a short window for quick admin insight, not meant to be a full analytics solution. The underlying data, however, is stored longer (depending on your environment’s log retention configuration), so you can query more than 7 days yourself. Impact your Business with Metrics

2. Where the data is stored (DB / entities)

For the kind of information shown in your screenshot:

• Web screen views / screen requests

  • Main entities in the PlatformLogs extension:
    • Log_Screen – per screen execution; filter Screen_Type = WEB. Monitoring/Web requests in system table?
    • Log_RequestEvent – request-level events (used in Screen Logs). Monitoring/Web requests in system table?
  • DB view often referenced: OSLOG_SCREEN (points to the current screen log table in the log cycle). Monitoring/Web requests in system table?

• End-user accesses

  • Also derived from those log entities (request events + screen logs) — essentially counting distinct requests / sessions from end users (not IT users).

So the charts you see in Service Center are calculated from these log tables/views, not from some separate “analytics-only” database.

3. Built-in tools vs. custom dashboard

Built‑in options you can use

• Service Center – Monitoring
  • Screen Requests / Web Requests: good for checking performance and screen usage for a given period, but UI is limited and not very customizable. How to check the action time on the screen
• LifeTime Analytics
  • Gives insights into end‑user experience, screen response time distribution, screens getting slower, etc. Application performance measure
  • However, it’s mostly charts and aggregates, not “pure data” for arbitrary timeframes and custom KPIs.

When you need more than that

For requirements like:

• “End-user accesses on 27/7/2026”
• Custom ranges (e.g., 3 months, 1 year)
• Custom aggregations (per user, per app, per screen, per portfolio)

You typically need a custom solution:

1. Read from the log entities (Log_Screen, Log_RequestEvent, or OSLOG_SCREEN).
2. Aggregate per day, per user, per screen, etc.
3. Store or expose that data in your own application.
4. Build dashboards (charts, tables) in your module.

OutSystems explicitly encourages this for metric needs beyond the built‑in dashboards, including combining log data with external sources. Impact your Business with Metrics

4. Practical approach to build your dashboard

Here’s a straightforward pattern that works well in O11:

1. Use PlatformLogs extension

   • Add dependency to PlatformLogs.
   • Use Log_Screen and/or Log_RequestEvent in aggregates or SQL to get:
     • Date/time of access
     • Application
     • Screen name
     • User (if available)
     • Duration, etc.

2. Define your own “User Activity” entities

   • Example:
     • UserActivityDaily (Date, Application, Screen, UserId, Count, AvgDuration, MinDuration, MaxDuration, etc.)
     • Or keep it more granular and aggregate on-demand if volumes are small.

3. Create a scheduled job (Timer)

   • Runs every X minutes or once per day.
   • Reads new logs from PlatformLogs (e.g., “logs after the last processed timestamp”).
   • Aggregates and writes into your UserActivityDaily entity.
   • This avoids heavy direct queries on the raw log tables from your dashboards.

4. Build the dashboard

   • Reactive web app with:
     • Date range filters
     • Application / screen filters
     • Charts:
       • End‑user accesses per day (like Service Center, but for any period).
       • Screen views per day.
     • Tables for drill‑down.

5. Optional: use the Performance Monitoring API

   • OutSystems provides a PerformanceMonitoring API for performance-related data, which you can also consume. Application performance measure

6. Consider the OutSystems log REST component (Forge)

   • There’s a Forge component that exposes log data as REST, making it easier to centralize and integrate with external tools. Impact your Business with Metrics

5. Retention considerations

• The log retention period depends on your environment configuration and infrastructure (self‑managed vs. OutSystems Cloud).
• For truly long‑term analytics (years of data), many customers:
  • Periodically export logs (or your aggregated UserActivityDaily records) to an external data store / BI tool (e.g., Power BI, Elastic, etc.). Impact your Business with Metrics

6. Direct answers to your questions

Do we have a built-in tool/web that I haven’t found yet?

You have:

• Service Center Monitoring
• Service Center home dashboard (7 days)
• LifeTime Analytics

But none of them will give you fully customizable time ranges and KPIs like “End-User Access on 27/7/2026” in a flexible dashboard. For that, a custom dashboard on top of PlatformLogs (and/or exported logs) is the usual approach.

Can I know which database they use to show on the charts above?

They use the platform log tables/views, accessed via the PlatformLogs extension, especially:

• Log_Screen (screen executions; for web screens filter Screen_Type = WEB).
• Log_RequestEvent.
• The DB view OSLOG_SCREEN (when querying directly). Monitoring/Web requests in system table?

If you base your aggregates on these entities, you’ll be reading from the same data that Service Center uses, but with complete control over timeframe and visualization.