Portals
Your customers write into GitHub without ever seeing it
A portal is a space at a subdomain of pealboard.com where people with no GitHub account submit requests and watch them move. Every request is one GitHub issue, in the repository you chose, with the labels and project fields you chose.
What a customer does
Signs in
Enters an email address, receives a 6-digit code, types it in. No password, no GitHub account, no software to install.
Chooses a request type
Bug report, Feature request, Question, or whatever types you defined. Each one has its own form and its own destination in GitHub.
Fills in the form and submits
The page states what happened, exactly: "Request ACME-42 was created. You will get an email when its status changes or when someone replies."
Follows it
My requests, company requests and public requests, each with one of seven status words and the date it last changed. They can comment, and vote on public requests.
Request types and destinations
You decide where each kind of request lands
A request type is a form plus a destination. The destination is what makes a portal write into the right place instead of into a queue somebody has to move things out of.
| Field | Required | What it does |
|---|---|---|
| Repository | Yes | Where the issue is created |
| Labels | No | Applied on creation. A label that does not exist yet is created |
| Project | No | The new issue is added to it as an item |
| Initial field values | No | Set on creation, for example Status = Triage |
| Issue type | No | The organization's issue type, if you use them |
Every issue a portal creates also carries the label portal:<slug>, so an engineer looking at the repository in GitHub can tell where it came from.
Visibility
Per request, not per portal
A portal's default visibility decides only what a new request starts as. A member, or a customer with the manager role, changes any individual one.
- Private
- The requester, and every member of the workspace.
- Company
- Everyone in the requester's company, and the workspace. A customer never chooses their own company: it comes from the invitation, or from their verified email domain.
- Public
- Everyone signed into that portal, and the workspace. Public requests can be voted on, one vote per customer.
What is never visible at any visibility: the repository name, the issue number, the assignee, the labels, the milestone, another portal's requests, and every internal comment.
Statuses
Seven words, derived from the issue, never stored
Your internal Status options — Triage, Blocked, In review, Needs design — are yours. They collapse into one of these seven and are never shown to a customer. Renaming one changes nothing a customer reads.
| The customer reads | When |
|---|---|
| Open | Nothing below applies. The fallback. |
| Planned | The project’s Status field is Planned or Todo |
| In progress | The project’s Status field is In progress |
| Waiting on you | The issue carries the label needs-info |
| Completed | Closed as Completed, or the project’s Status is Done |
| Merged | Closed as a duplicate |
| Closed | Closed as Not planned |
Because status is derived rather than stored, closing an issue in GitHub changes what the customer sees within seconds. Nobody has to remember to update the portal, and the portal can never disagree with GitHub.
Comments
Nothing crosses unless a member sends it
A member answers from the issue: type the comment, turn on Reply to portal, send. That comment appears in the portal and the requester is emailed. Every other comment on the issue is internal, and a customer cannot reach it.
- A public comment carries a Public badge in the workspace, so the difference is never carried by color alone.
- The customer sees the workspace's name and the time. Not your GitHub login, not your email address.
- A customer's own comment is written to the GitHub issue with a footer naming them and their company — never their email address.
- One portal setting, Show every GitHub comment to customers, opens the whole thread. It is off by default.
Attribution
The engineer can see who asked
An issue created through a portal carries one line at the top of its body naming the requester and their company, and a hidden marker Pealboard uses to reconnect the issue to its request.
> **Requested by** Jane Doe (Acme) through the [Acme portal](https://acme.pealboard.com/requests/ACME-42).The visible line carries a display name and a company, never an email address, because a body Pealboard authored can be rewritten later to honor a deletion request and an issue in GitHub cannot be recalled. The hidden marker survives an edit by someone who does not know what it is.
Branding and access
Your name on it, and only the people you meant
A portal carries your logo, your accent color, your name and your welcome text. Pealboard is named once, in the footer.
| Access mode | Who can sign in |
|---|---|
| Invite only | Only people a member invited |
| Domain allowlist | Anyone with a verified email address at a domain you listed |
| Open | Anyone. A new customer's first request waits in the hold queue until a member releases it |
Every portal form carries Cloudflare Turnstile. If you set an accent color whose contrast against the page is too low, the portal darkens it along its own hue until it holds and shows you the value it used. A color is never used at a ratio nobody measured.
Questions
- Does a customer need a GitHub account?
- No. A customer signs in with a 6-digit code sent to their email address, or with a sign-in link. There are no passwords, no GitHub account and no invitation to create one.
- Are portal customers billed?
- No, on every plan, at every volume. Billing counts workspace members only — the owner, admin and member roles. Viewers, portal customers and companies are never counted.
- Can a customer see our internal comments?
- No. A customer sees comments written in the portal and comments a member wrote with Reply to portal. Every other comment on the issue is internal. A portal setting can show customers every GitHub comment; it is off by default and turning it on is a deliberate act.
- What does the engineer see in GitHub?
- An ordinary issue. The body carries what the customer filled in, under headings, and one line naming the requester and their company — never their email address. A reply a member made public carries a footer saying so. Nothing else about the issue is unusual.
- What happens if we delete a portal?
- The portal, its customers, its companies and its request records are deleted. Not one issue in GitHub is changed: they stay open, with their comments, in the repositories they were created in.
One portal is free
The Free plan includes one portal with unlimited customers. Team allows five, Business is unlimited. Portal customers are never billed on any of them.