Short answer

Add them as a user and give them a defect-reporter permission set: they can view assets and report defects (create, edit and delete their own defects, and view all defects), but they can't see or create inspections, jobs or routines, and can't manage assets, users or settings. It's the safe way to bring known, named reporters — councillors, and volunteer groups such as In Bloom gardeners — onto the app: they can flag issues from the field, but there's nothing for them to break and no work-scheduling layer for them to clutter. This is for people the council knows and adds as users — not the general public (public reporting is a separate feature planned for late 2026 / early 2027; don't add members of the public as users to approximate it — see Watch-outs).

Detail

A common worry when councils think about putting councillors on the app is "will they just start chucking jobs on willy-nilly?" The answer is no, because you control exactly what a user can do through their permissions. The right shape for a councillor, a volunteer (e.g. an In Bloom gardener reporting planter problems), or any other named issue-reporter is a cut-down set built around defects only.

When you add the user (top-right app switcher → Manage Account → your current users → add user), set their permissions so that across the five areas — assets, inspections, jobs, defects, routines — they have:

  • Assets — view only. They can see the asset register (so they can pick the right bench/tree/bin to report against) but can't create, edit or delete assets.
  • Inspections — none. They can't view or create inspections.
  • Jobs — none. They can't view or create jobs. This is the bit that stops them "adding work" — scheduling is left entirely to the staff.
  • Defects — view any, plus create / edit / delete their own. This is the active capability: they raise a defect against an asset, attach a photo, describe the issue.
  • Routines — none. The recurrence layer is a supervisor concept; reporters never see it.

What it looks like for them: they open the app to an (intentionally sparse) empty task list, tap + → Defect, see the assets nearest to where they're standing, pick one, replace the photo with a shot of the actual problem, and type a short description (e.g. "branch broken"). The defect then flows into the web app for staff to triage into jobs — see How does the defect workflow work — from a failed inspection to resolution?.

Why "view any defects" matters: giving reporters visibility of all defects (not just their own) is the interim way to cut down duplicate reports — before raising one, they can see the issue's already been logged. (A clearer "this asset already has a defect" marker on the map is on the roadmap.)

Rollout tip: onboard reporters in one controlled session rather than emailing invites cold. Create the accounts together, walk everyone through creating a defect out in the field, and let them see each other's reports appear. Start with a small, tech-savvier group (3–4 people) and expand once they're comfortable — it keeps control and avoids overwhelming a cautious group. Onboarding councillors or a volunteer group this way is also a good practice run for the council ahead of the dedicated public-reporting feature landing (see Watch-outs).

Watch-outs

  • There's no deactivate — only delete. When a councillor leaves, you remove them by deleting the user (reassign anything outstanding first). See What can a Field Operative actually do in Civic.ly? and How do I add a new user to a Civic.ly account?.
  • Don't reach for TENANT_ADMIN for convenience. A reporter needs far less than admin; the defect-only set is the right minimum.
  • The empty task list is expected. A defect-reporter has no assigned work, so their app home looks bare — reassure them that's normal; they create from the + button.
  • This is a permission set, not a fixed named role. Custom permission sets are supported, so you build the shape above per user — don't expect a one-click "councillor" role.
  • Don't use this to put the general public on the app. The defect-reporter set is for known, named people the council adds as users (councillors, staff, named volunteers) — not for opening reporting to residents at large. Public reporting is a distinct feature planned for late 2026 / early 2027; until it ships, don't create user accounts for members of the public to approximate it. Volunteer groups (e.g. In Bloom) are fine because they're a defined, named set the council manages — the public is not.