Who’s Knocking? Tracking Slate Portal Access with Logins + Pings

Scenario

Picture this: Your institution just launched a shiny new Slate portal—maybe a status portal, an application portal, or a slick custom admin dashboard like the ReWorkflow Admin Portal. The goal? Know exactly who’s coming through the door, how often, and what they’re doing once inside. The reality? Without a little behind-the-scenes wiring, you’re left piecing together footprints in the sand: a login here, a pageview there, but no unified picture of portal access.

Problem 🤝🏻 Solution

By default, Slate gives you two powerful (but separate) lenses:

• User Login Data – every time someone signs into a portal, Slate logs the event with time, browser, platform, IP, and more.
• Ping Data – every time a page with the Ping snippet loads, Slate captures URL, timestamp, device, browser, IP, and a unique cookie.

The challenge? Alone, each data stream tells only half the story. Logins tell you who came in, but not what they did. Pings tell you what happened on a page, but not always who was behind it.

The trick is combining them. Once a user authenticates, Ping and Login data can be tied together, creating a complete picture of portal access and behavior.

How it works:

• Enable Ping Everywhere
  • Add the Ping JavaScript snippet to all portal pages (easy toggle in Slate under “Embed Ping on Slate Pages”). This ensures every pageview is tracked.
• Capture Logins
  • Use the Person Login query base (Configurable Joins → Related → Person Login). Each event stores IP, browser, login time, and portal name.
• Marry Ping + Login Data
  • Once a user authenticates, Ping rows and Login rows can be linked to the same person record. Now, instead of isolated events, you can report on:
    • Who logged in
    • Which portal they accessed
    • Which pages they viewed inside
    • How long they spent there

Here is an example from ReWorkflow database:

Example 1: Tracking all Portals

SQL

Slate Query Configuration

This version scales across all Slate portals—status, app, custom—so you can monitor logins and activity in one sweep.

Example 2 : Isolating a Specific Portal (ReWorkflow Admin Portal)

SQL

Slate Query Configuration

This query pulls today’s ReWorkflow Admin Portal logins, pairs them with Ping activity, and shows you who actually went into the portal.

Best Practice: Make Ping + User Login Your Dynamic Duo

• Use Person Login for a reliable who + when.
• Use Ping for detailed what + where.
• Combine them to see who did what, when, and where.

This not only helps with portal adoption reporting but also flags suspicious access (multiple IPs, odd locations) and measures engagement (did they just log in, or did they explore?).

Final Thought

Portals are meant to be living, breathing extensions of your Slate instance, not black boxes. By stitching together Login and Ping data, you turn disconnected events into a coherent activity trail. Want to know who’s knocking, when they walked in, and what they did once inside? That’s no longer guesswork. With Slate, the door is wide open, you just need to track the footsteps.