Issue ticketing across organizations
This guide is for teams adopting portablemind's cross-organization issue ticketing: a service provider — Istonish, in our running example — supporting software applications used by many State Agencies.
It covers three things: what the solution is, why it works the way it does, and how each person on your team uses it day to day.
Each agency files and tracks issues in its own private workspace; the provider automatically receives and works all of them.
Employees report issues against the software applications they use. Their agency sees its own issues; the provider sees them all. Four building blocks make that work.
Every agency gets its own private workspace. Its employees, its issues, its data — invisible to every other agency, automatically.
isolation by structureEvery issue an agency files flows to the provider the moment it's created — no forwarding, no export. The provider works one queue across all agencies.
automatic, standingEach software application (and the Program it serves) is a Project the provider owns. Agencies are granted access to exactly the applications they're entitled to.
provider-owned master dataAn issue names its application, carries priority and status, and can link to the fix task — so reporters see Planned → In progress → Shipped without asking.
from report to roadmapThe design choices below came out of the refinement with Istonish. Each one favors something structural over something you'd otherwise have to police with rules and memos.
An agency is a workspace, not a folder with permissions. Nothing to configure, nothing to get wrong — another agency's issues simply do not exist in your view.
A reporter can delete an issue until the provider acknowledges it. After acknowledgement, the provider administers it. One timestamp settles ownership without complicating the status workflow.
When the same defect is reported twice — even by two different agencies — the duplicates are linked to one canonical issue and closed. Nothing is deleted, so a merge can be reviewed and reversed.
The provider can make one issue visible to any set of agencies (a known-issue notice, a shared defect). A published issue shows its full content, including who reported it — visibility is explicit, never accidental.
By default, everyone in an agency sees all of that agency's issues. If an agency prefers employees to see only the Programs they belong to, that's a per-workspace switch — off until you ask for it.
Every rule that matters — who sees what, who may delete, who owns an issue — is enforced by the platform itself, not by convention. Your auditors will like that as much as your users do.
Three roles touch the system: agency employees who report issues, agency admins who run their workspace, and the provider team that works the queue.
Agency employees — report & follow
Agency admins — run your workspace
Provider team — work the queue
Two project concepts sound alike and get confused constantly. They answer different questions, live in different places, and only one of them affects what an employee can see.
Project → Members tab
Who belongs to this Application or Program.
Tasks → assignees
Who is working on which task, and when.
Members decide who can see. Assignments decide who does the work. Neither one implies the other.
Why the distinction matters: when your agency turns on per-Program visibility, an employee's view of the ticket queue is defined entirely by Program membership. Assigning someone a task does not let them see the Program's issues, and adding a member does not put them to work. If someone "can't see a ticket they should," check the Members tab — not the task's assignees.
When you add a member, you pick the role that best describes them. The role is a label for people — it says what someone is on the team, so the member list reads like an org chart instead of a flat list.
team · standard
A working member of the project or Program — the everyday role, and the default when you add someone.
team · lead
Marks who runs the project or Program — the person to ask, the name reviewers and approvers look for.
team · observer
Someone who follows the project without actively contributing — a stakeholder, a sponsor, an auditor.
One thing all three share: each one makes the person a member, and any active membership — whatever its role — is what grants issue visibility when per-Program visibility is on. The role describes the person; it does not add or remove project permissions.
Off by default — every agency starts with agency-wide visibility, and nothing changes until you opt in. When you do, employees see only the Programs they're members of.
Request the switch for your workspace from your provider or platform contact. It's a per-agency setting — your choice never affects other agencies.
Before it goes live, have your admin add each employee to the Programs they work with — Application → Members tab. Anyone not yet a member of a Program stops seeing that Program's issues the moment the switch flips.
Spot-check as an employee: the ticket list should show only their Programs' issues (plus any issue not linked to an application, which stays visible to everyone in the agency).
The fine print: matching is strict — even an issue an employee filed themselves disappears from their view if they're not a member of its Program. Issues with no application link remain visible to the whole agency. The provider's view is never affected. And issues shared directly with a person stay visible regardless.
Everything in this guide is live in your workspace today. Your portablemind contact can walk your team through any of it — or just start with one test ticket and watch it flow.