What the Activity screen is

The Activity screen is MAM Suite’s screen type for location-based check-in and field work. A normal listing screen is something a user browses. An Activity screen is something a user does: they arrive at a place, check in, do the work, and end the activity — and the app records where they were, when, and (optionally) how they got there.

Ask yourself whether your app needs to answer questions like “was the technician actually on site?”, “which route did the driver take?”, or “who signed off at each stop?” If so, the Activity screen is the piece that captures it. If your app is purely content — articles, products, a directory people browse — you almost certainly do not need it.

Activity is one of the configurable screen sections inside Mobile App Manager → App Settings, grouped under its own Activity settings category alongside the other screen categories (Listings, Calendar, and so on). Turning it on just means building an Activity screen and tuning its settings — there’s no separate plugin to install.

Why it matters: the check-in use case

Most MAM Suite apps are read-first — people open them to browse. The Activity screen is built for the apps that are work-first instead: the ones used by people moving through the physical world on behalf of an organization. Here are the shapes that keep coming up:

• Field service and inspections. A technician or inspector opens the app, sees their list of assigned locations, checks in when they reach one, completes the visit, and checks out. The app proves they were close enough to the site to be there.
• Routes and deliveries. A driver works a list of stops, with the app tracking the path between them and the time spent at each.
• Punch-in / check-in for shifts. Staff start an activity when they begin work and end it when they finish, giving the back office a record of attendance tied to a location.

The common thread is presence plus a time window. The app isn’t just showing information — it’s recording that a specific person was at a specific place for a specific stretch of time, and gating that record on how physically close they actually were.

The lifecycle of an activity

Every activity moves through the same arc, and most of the Activity settings exist to shape one stage of it.

1. Start / check-in.
The user picks a location and checks in. The main control here is the allowable check-in distance — the maximum distance (in feet) someone can be from the location and still check in. Set it to 0, or leave it blank, to remove the distance limit entirely. When you do enforce a distance, you can optionally allow an override so a user who isn’t close enough can still check in, with a custom override title and message explaining what’s happening (for example, “You’re not at the site — check in anyway?”). Want details captured before the work starts? Require a start form at check-in.

2. In progress.
Once checked in, the item is “in progress.” Activity settings let you make in-progress items visually obvious in the list (a colored bar), keep the list fresh by reloading every five minutes, and add a refresh button to the tab bar for manual reloads. While an activity is in progress, the app can also track GPS — sending periodic location pings and recording markers along the route, with a configurable minimum distance between markers so the trail doesn’t get cluttered with near-duplicate points. There’s even a speed-based auto-close: the app can prompt the user (or end the activity automatically) once their measured speed passes a configured MPH threshold — this is how you’d express a “they’re clearly driving away, the visit is over” rule.

3. End / check-out.
The user ends the activity. You can require a confirmation dialog so it isn’t ended by accident, and a single signature toggle (Require signature for activities at each location) collects an end-of-visit signature and combines it per location — so one signature covers the whole stop instead of one per item.

The settings you’ll see in the Activity category aren’t a random pile of toggles, then. Each one corresponds to a decision about one of these three stages: how strict is check-in, what do we record while you’re there, and what do we require to close out.

How Activity relates to the other pieces

The Activity screen sits next to a few neighboring features, and it’s easy to mix them up. Here’s where the lines fall.

• Activity vs. the Punch Out button. MAM Suite also has a Punch Out content class — a standalone punch-in / punch-out button for time tracking, with its own server-side geofence check. Punch Out is a single button answering “are you on the clock?”. The Activity screen is a whole list-and-map workflow answering “which stops did you visit, in what order, and what happened at each?”. An app can use one, the other, or both. If all you need is shift start and stop, Punch Out is the lighter choice; if you need per-location check-ins and routing, reach for Activity.

• Activity vs. plain Listings. An Activity screen is built on the same list mechanics as a Listings screen (it shares list-level controls like the refresh button), but it adds the check-in lifecycle on top. If your users only need to read the items, a Listings screen will do; reach for Activity only when they need to check in against the items.

• Activity and location / GPS. Because check-in is distance-gated and GPS pings are optional, the Activity screen depends on the device granting location permission. If your audience won’t grant location access, the distance gate and route tracking won’t work as intended — so factor that in before you turn on distance enforcement.

When to enable it (and when not to)

Enable the Activity screen when:

• Users go to places on the app’s behalf (service calls, inspections, deliveries, route stops).
• You need a record that someone was physically present, and/or proof-of-distance at check-in.
• You want route tracking, on-site signatures, or start/end forms tied to a location.

You probably don’t need it when:

• The app is content- or commerce-first and users simply browse.
• You only need shift attendance with no per-location workflow — consider the Punch Out button instead.
• Your users can’t or won’t grant location permission, which undercuts the distance and GPS features.

A good rule of thumb: if you can’t name the locations people check into and the thing they do at each one, the Activity screen isn’t the right tool yet.

What’s next

• To see the individual toggles and what each one does, browse the Activity settings in App Settings; each setting has its own reference entry (check-in distance, override prompts, start form, end dialog, GPS pings, marker distance, speed-based auto-close, per-location signatures, and the in-progress/refresh display options).
• If you only need shift-style time tracking, read the Punch Out content class reference instead.
• For how Activity differs from a browse-only screen, see the Listings screen reference.