Service Portal

Service Portal gives you a public, branded intake surface where people outside your organization — customers, contractors, members of the public — can submit a request without needing a login. Each submission lands in your workflow as a tracked record with a public reference number, and the submitter can follow its progress and reply, all from a link.

Service Portal is included with every Aptli plan — there's nothing to unlock. Any admin with the Service Portal management right can create a portal and start collecting submissions right away.

What it's for

Use it when…	Example
You need to collect requests from people who don't have accounts	A resident reporting a damaged utility pole
You want a consistent, branded, map-based form instead of email free-text	A contractor requesting a site locate
Submissions should enter your workflow and be tracked to resolution	A service request that becomes a work order and a report

The lifecycle at a glance

        ADMIN SETUP                 PUBLIC SUBMISSION              TRIAGE & TRACK
   ┌────────────────────┐      ┌────────────────────────┐   ┌───────────────────────┐
   │ Build a portal      │      │ Visitor opens the link │   │ Operators are notified │
   │  • forms + fields   │      │ (or scans the QR code) │   │ New submission lands   │
   │  • map layers       │ ───► │ Picks a form            │──►│ in the Inbox           │
   │  • branding         │      │ Drops a point/line/area│   │  • set status          │
   │  • sharing (link,   │      │ Fills fields + photos  │   │  • add public/internal │
   │    QR, embed)       │      │ Submits → gets a       │   │    comments            │
   │ Publish             │      │ reference number       │   │  • link a work order,  │
   └────────────────────┘      └───────────┬────────────┘   │    report, or feature  │
                                            │                └───────────┬───────────┘
                                            ▼                            │
                                ┌────────────────────────┐              ▼
                                │ Submitter tracks status │   ┌───────────────────────┐
                                │ at /portal/<slug>/<ref> │◄──│ Status change emails   │
                                │  • sees progress        │   │ the submitter          │
                                │  • reads public replies │   │ (new → in review →     │
                                │  • can reply back       │   │  actioned → closed)    │
                                └────────────────────────┘   └───────────────────────┘

How it works

You build a portal — either from scratch or by starting from a ready-made pack of common request types for your industry, in a short setup wizard. A portal hosts one or more forms (e.g. "Report a hazard", "Request a locate"), each with its own fields (name, text, multi-line text, number, yes/no, choice, date, date & time, email, URL, location, address, attachments), map pin colour, and icon.
You share it — every portal's Share panel gives you a link, a QR code you can view, copy, and print, and a one-line embed snippet to drop the portal into an existing website. You can also serve it from your own domain instead of the default address (see Sharing a portal).
The submitter fills it in — anonymously, from any device. Location is captured from the device or drawn on the map as a point, line, or area. The public map also shows the shapes of prior submissions nearby, so people can see what's already been reported.
A record is created — stored with a public reference number, the submitter's language, the geometry, and any attachments. If they provided an email, they get a confirmation with that reference.
Operators are notified — staff subscribed to the portal get a bundled email and push notification, deep-linked to the new submissions. Arrivals within a short window are batched into one notification rather than one per submission.
You triage it in the Inbox — filter (including by proximity on a map), open a submission to see its details and geometry, set its status, add comments, and turn it into a work order, report, or map feature (see below).
The submitter stays informed — when the status changes, they get an update email referencing their public number, and they can return to the tracking page to read replies and respond.

Submitting: describe it, or pick a form

The portal opens with a "Report an issue" composer: the submitter can just describe the problem (typing, or dictating with their device's voice input) and attach a photo, and Aptli picks the right form for them — or they can choose a service from the list directly. When AI is available, the described text and photo route to the best-matching form, and a "Fill for me" option pre-fills the fields for the submitter to check and adjust. It's a lower-friction front door than making a member of the public find the correct form themselves; the plain form picker is always there as the fallback.

Where a submission goes: convert it into work

Triage isn't just status changes — a submission can become real work through the submission actions, grouped Create and Link:

Action	Result
Create Work Order / Link Work Order	Spin up a new work order from the submission, or attach it to an existing one.
Create Report / Link Report	Same, for field reports.
Create Feature	Propose the submission's geometry and values as a map feature — staged into the Version Approval Queue for admin review, not written directly.
Record Stock Change	Turn it into an inventory transaction (Materials add-on required).
Run automation	Manually fire one of your automations against this submission — a supervisor's judgment call instead of waiting for a rule to trigger.
Forward for follow-up	Hand the submission to an external system — see Forwarding to an external system.

Each created or linked record is tracked on the submission, with View and Unlink. When every linked record reaches a terminal state the submission becomes ready to close, and can auto-close if you've enabled that. Reopening a closed submission requires a reason.

De-duplicating repeat reports

Ten calls about the same pothole shouldn't be ten separate jobs. Two tools handle that:

Consolidate into… — manually pool one submission under another; the pooled one shows as "Pooled under" its parent (and can be un-pooled).
Bundle — an automated grouping pass over the current submissions that proposes clusters by error type, by distance (within a radius you set), by submitter, or by similarity. You review the proposed bundles, pick a head for each pool, and apply — turning a flood of duplicate reports into one tracked item with the rest pooled under it.

The submission status journey

Every submission moves through four states. The submitter sees this as a simple progress bar:

   NEW  ───►  IN REVIEW  ───►  ACTIONED  ───►  CLOSED
   just      an operator      turned into      resolved;
   arrived   is looking       real work        no further
                              (linked record)  action

Status changes notify the submitter (internal notes do not), and rapid back-to-back changes collapse into a single message.
Reaching a configured status can graduate the submission's drawn geometry onto a real map layer, so an approved report becomes a feature on your map.

Tracking and two-way replies

Each submission has a public tracking page at its reference link (/portal/<slug>/<reference>). From there the submitter can:

See the current status on a progress bar.
Read public comments from your team — staff names are never exposed; replies show as coming from the portal.
Post a reply, which appears in your triage thread.

Internal comments stay staff-only and are never shown on the tracking page.

The submitter can also add photos or files to an existing submission from the tracking page ("Add to submission") — useful when they have more evidence after the fact. Once a submission is closed, the reply box is replaced with a note that it's resolved and no longer accepting replies.

My submissions

Because there are no public accounts, the portal remembers a person's submissions on their device. The My submissions list re-looks-up every reference number they've filed from this browser, newest first, with its current status — so a resident can check everything they've reported without a login or saving reference numbers by hand. (Clearing browser data clears the list; the reference number is always the durable way back to a single submission.)

Forwarding to an external system

Forward for follow-up hands a submission to an external automation — a partner's ticketing system, a legacy work-management tool — as a genuine, honest, one-way hand-off. It does not advance the submission's status; the submission stays in your triage. A single-use, expiring callback link travels with the forwarded payload, so the external system can POST its result back exactly once.

The submission shows the state of that hand-off: Forwarded → Awaiting response → Responded (or Expired / Revoked). You can revoke the callback at any time, and open the item in the external system if it returned a link.

Publishing feed content on the map

A portal can also show visitors something other than a form — a live feed of published items rendered as pins and shapes on the public map, each with a link to read more. Connect an external feed (for example, a news or announcements feed) to a portal's Content tab, and new items become tracked, unpublished-until-placed entries:

If an item already carries a location, it's placed automatically.
If it doesn't, your team places it on the map from the Content tab, or sends a login-less placement link to whoever knows where it belongs — no account needed on their end either.
Once placed, an item is live on the portal's public map with a shareable link and its own QR code. You can conclude an item at any time to retire it from the map.

This is a separate, optional capability from submission intake — a portal can do either, or both at once.

Every portal has one place to manage how the public reaches it — its Share panel, opened from a portal's card or its menu:

Public link — copy it directly.
QR code — view, copy, or print it. A QR codes page also shows every portal's code in one print-ready grid, filterable by published/draft.
Embed snippet — a single line of code that drops the portal into an existing website as an embedded frame, with a short how-to for common site builders.
Custom domain (white-label) — by default a portal lives at an aptli.io address; the Share panel lets you serve it from your own domain instead — report.yourcity.gov rather than the default — for a fully branded intake surface. You point a CNAME at Aptli (or, for a root/apex domain with no subdomain, an A record at our IP), Aptli verifies the DNS and issues a certificate automatically, and the portal then answers on your host.
Public address override — if your own site sits in front of the portal at a different path, you can tell Aptli the address the public actually sees, so links, QR codes, and notifications always point somewhere real.

The Portals page

The Portals page is your front door to every portal you run: a card per portal showing its public address, whether it's served from the default address or your own domain, and at-a-glance stats — new submissions this week, how many forms it has, how many languages it supports, and a warning if it has feed content waiting to be placed. A dashed "new portal" card starts the setup wizard, which offers a ready-made starting pack for common request types before handing you off to Share once the portal is built. Each card's menu covers the everyday actions: set up a domain, share, view history, print a QR code, publish or unpublish, and delete.

The Inbox

The Inbox is where your team works submissions day to day: status-lane chips with live counts (new, in review, actioned, closed), a searchable and filterable case list (by portal, status, location, and more), and bulk actions for handling several submissions at once. Opening a submission expands into its full case view — the conversation and public replies on one side, and a rail with the status control, close-and-notify, the submitter's details, and every linked record (work orders, reports, map features, forwarded tickets) on the other. Each person can set their own notification preferences for which portals and events they hear about.

Reviewing portal configuration history

Every change to a portal's own setup — its forms, branding, sharing settings, anything in the editor — is kept in a history you can open per portal, so you can see who changed what and when, independent of the submissions it's collecting.

Helpful capabilities

Multiple forms per portal — group related intake types under one branded portal, each with its own fields and map styling.
Photo-assisted fill (optional) — when enabled, an uploaded photo can pre-fill form fields to speed up submission. It's off unless you turn it on.
Branding & translations — the public form carries your logo and colours, and can present in the submitter's language.
Map context & legend — show selected layers (optionally filtered) so submitters place their request against real-world features.

Key concepts

Public reference number — every submission gets a short, shareable number. It carries no internal identifiers and is safe to expose; it's how the submitter follows up.
Language capture — the submitter's language is recorded so confirmations and follow-ups go out in the language they used.
Rate limiting — public endpoints are rate-limited to prevent abuse; spam never reaches your workflow.
Attachments — files are stored and linked to the submission, size- and type-checked before they're accepted.

Configuration

Service Portal settings live in the portal editor, visible to holders of the Service Portal management right. The editor is organised into tabs:

Basics — the portal's name, publish state, and branding (logo, colours, page title).
Forms — create and edit intake forms, set required fields, choose the post-submission action and the layer that approved submissions graduate to, and publish/unpublish each form.
Map data — choose which map layers the public sees (with optional per-layer filters and labels) and scope what the public form can do and show.
Works — appears when relevant, for portals that surface work happening nearby.
Content — attach a feed and manage the published map content described above.
Languages — provide the portal's copy in each language you support.

Sharing and custom-domain setup live in the Share panel, not in the editor tabs — see Sharing a portal.

Limits and safeguards

Submissions are append-only from the public side — a submitter can add attachments and replies, but can't edit the original fields or delete the record.
Rate limits and required-field validation run server-side, so a crafted request can't bypass them.
Every triage action, link/unlink, status change, and reopen is recorded on the submission's own History tab, keeping a clean audit trail.

Need a field type or workflow hand-off that isn't covered here? Service Portal is configurable per deployment — reach out and we'll scope it.