Guest Portal
The Guest Portal is the stripped-down version of the Appello web app shown to an invited
external contact -- a customer's site representative, property manager, or other
stakeholder given Guest User Access on their Contact record. It is not a separate
product: a guest signs in at the same /signin screen as everyone else, but every route
outside /guest/** redirects them straight back, and every page under /guest/** is
narrowed to read a handful of records the guest was explicitly given access to.
This page documents the guest experience: what each /guest/** screen shows, how a
contact becomes a guest, how a guest signs in, and what a guest cannot do. For the
CRM-side invite mechanics (Contact records, other Settings-tab fields), see
Contacts. For sign-in, password, and invite-link mechanics shared
with regular users, see
Sign In, Password and PIN Reset, Invite Onboarding.
The crawl session used to research this page is signed in as an admin account on the demo instance, not a guest account. Every guest page re-checks that the signed-in user really is an active guest before rendering anything (on load, and every 10 seconds after); for a non-guest session that check never passes, so the page sits on a permanent "Validating Guest User" spinner instead of showing real content. This was confirmed by loading the guest portal in the crawl session and observing exactly that spinner -- no further screenshots were possible this way, and there is no guest account provisioned on the demo instance to sign in as instead. Everything below -- screens, columns, gates, and workflow -- is described from Appello v1.33 rather than from screenshots. This is the same pattern used in Dropbox Sign E-Signature for a feature this review could not reach live.
How a guest is invited
A guest account is created from a Contact record, not from the Users list. On the contact's own Settings tab (Sidebar → CRM → Contacts → a contact → Settings), the Guest User Access card lets an admin send an invite. See Contacts → Guest User Access for the click path and the card's own fields (Send Email Invite, Resend Email Invite, Reset Password, the Invited / Active status). This section adds the mechanics behind that card:
- Clicking Send Email Invite creates a guest user account, assigns it the guest-user role, links it to the Contact, and -- at that moment only -- connects it to every company the contact currently belongs to. It also stamps the contact's Last Invited date and emails an invite link (see How a guest signs in below).
- If an account with the same email already exists and is itself an orphaned guest (no live contact left on it), Appello relinks that guest user to the new contact instead of creating a second one. If the email belongs to a live, non-guest user, or to a guest user still attached to another live contact, the invite is rejected with an error instead of silently merging accounts.
- Once a guest user exists, two more controls appear on the same Settings tab:
- Guest User Portal Status -- a Disable / Active toggle. This flips the guest user's active status. Disabling it does not delete the account; it is the fastest way to cut off portal access without waiting on a password reset.
- Associated Companies -- one accordion panel per company the guest's contact belongs to, each with its own Portal Access toggle. Turning a company off removes it (and every project/job under it) from what that guest can see; the contact's current company cannot be turned off. Expanding a company panel reveals per-project and per-job access toggles for that company specifically: toggling a project on/off cascades to every job on that project, and toggling an individual job on also turns its parent project on (so the job is reachable), but toggling a job off does not turn the project off. A Standalone Jobs (No Project) panel covers jobs with no parent project, toggled the same way. These per-project/per-job selections are what every guest list (see below) actually filters on -- being "in" a company via the toggle above is necessary but not sufficient; the specific project or job also has to be checked here.
None of this is exposed as a self-service guest action -- only a user with edit access to the Contact's Settings tab can invite a guest, disable the portal, or change what a guest can see. A guest cannot invite another guest, and there is no equivalent control inside the guest portal itself.
How a guest signs in
A guest signs in at the same /signin screen as any other user -- there is no separate
guest login page. See
Sign in for the form itself.
The guest-specific parts of that flow:
- The invite email (subject "Welcome to Appello,
<first name>! Set Up Your Account Now") links to/reset-password?token=<token>, the same page used for a self-service password reset -- see Reset password. The invite link lasts 7 days by default, versus 1 day for a self-service forgot-password link. Once expired, Resend Email Invite on the Contact's Settings tab issues a fresh one. - After setting a password, the guest is redirected to
/signin, signs in with their email and the password they just set, and on success is redirected to/guest-- a regular (non-guest) user is redirected to/instead. - An admin can also set a guest's password directly from the Contact's Settings tab (Reset Password button), bypassing the email link entirely.
Landing (/guest)
Where it is
The destination a guest lands on immediately after signing in. There is no menu item for it -- the Appello logo in the guest sidebar links back here.
What it's for
A routing page with no content of its own. It looks up the signed-in guest's contact record and immediately forwards the browser onward -- it never actually renders anything visible.
Workflow
- If the guest's contact has a current company set, redirect to
/guest/companies/{currentCompanyId}?tab=projects(that company's Projects tab -- see Companies below). - Otherwise (no current company on the contact), redirect to
/guest/companies, the flat list of every company the guest belongs to.
Sidebar
Guests get their own left-hand sidebar, populated differently from the main app: instead of the usual module navigation, it lists every company the guest's account is connected to and renders one nav item per company, each linking straight to that company's Projects tab. There is no Settings item and no Files item in the guest sidebar (both are hidden for guests), and the top navigation bar hides the global search box and the notification bell for guests as well.
Permissions and settings
Gate: the signed-in user must be a guest. Every guest page re-checks this (see the note at the top of this page) -- a session that isn't an active guest never gets past the "Validating Guest User" loading state. Separately, a guest who tries to open any non-guest page is sent back to the guest portal with "Guest users cannot access this page" -- a guest cannot reach the regular app by typing a different URL.
Related pages
Companies (/guest/companies, /guest/companies/[id])
Where it is
/guest/companies is the flat directory of every company the guest belongs to -- reached
from /guest when the guest's contact has no current company set, or by URL directly.
/guest/companies/{id} is a single company's record, reached by clicking a row on that
list, by clicking a company in the guest sidebar, or via the Home breadcrumb link on
any deeper guest page.
What it's for
/guest/companies lets a guest who belongs to more than one company (with no single
"current" one) pick which company to work in. /guest/companies/{id} is that company's
record scoped to the guest: a header with the company name, and two tabs -- Projects
and Jobs -- covering only the projects and jobs the guest was given access to on that
company (see How a guest is invited).
Screenshot
No screenshot -- see the note at the top of this page.
Columns
/guest/companies list:
| Column | Description |
|---|---|
| Company Name | Links to that company's /guest/companies/{id}. |
| Company Type | The company's Company Type. |
| Company Industry | The company's Industry. |
A Search Companies Name box filters the list; there is no create, edit, or bulk action on this page for a guest.
Company detail → Projects tab (filtered to this company and this guest's contact):
| Column | Description |
|---|---|
| Project | Number and name, links to /guest/projects/{id}?tab=forms. |
| Project Name | Same project, name only, same link. |
| Customer | The project's customer company name. |
| Location | City, state. |
Filterable by Project Name and Project Number; the table is read-only (no create, edit, archive, or delete for a guest).
Company detail → Jobs tab (filtered the same way):
| Column | Description |
|---|---|
| Job Number | Full job number, links to /guest/jobs/{id}?tab=safety-form. |
| Job Name | Same job, name only, same link. |
| Project Name | The job's parent project name, or "-" for a standalone job. |
| Job Contact | The job's primary contact. |
| Job Location | City, state. |
Filterable by Project; also read-only.
Workflow
- From
/guest, or by clicking a company in the sidebar, open a company's page (defaults to the Projects tab). - Click Jobs to switch tabs; the URL's
?tab=query param tracks the active tab. - Click any project or job row to open its own detail page (see below).
Permissions and settings
Gates: the user must be a guest (see Landing), plus Companies → View, Projects → View, and Jobs → View on the guest's role for the Projects and Jobs tabs respectively -- both tabs disappear if the role lacks the matching View permission, even though the guest-user role ships with them by default. Which specific companies, projects, and jobs actually return data is controlled entirely by the Associated Companies / per-project / per-job toggles on the guest's Contact (see How a guest is invited) -- permissions gate the tab, the contact's access list gates the rows inside it.
Related pages
Projects (/guest/projects, /guest/projects/[id])
Where it is
/guest/projects (the bare list URL) is not a real guest screen -- it immediately
redirects to /guest/companies. /guest/projects/{id} is a single project's record,
reached from the Projects tab on a company page, or from a job's breadcrumb.
Unlike the regular staff-facing app, there is no standalone "all my projects across every company" list for a guest -- projects are only browsed per company, from that company's Projects tab.
What it's for
A single project scoped to the guest: a header with the project number/name and two tabs, Form Submissions and Jobs, covering only that project's safety-form submissions and its jobs.
Screenshot
No screenshot -- see the note at the top of this page.
Tabs and columns
| Tab | Contents |
|---|---|
| Form Submissions | Every safety-form submission on this project. Always-shown columns: Submission ID, Safety Form, Submitted By, Submission Date/Time; a View Response > link opens the submission (see Safety Inspection Forms). |
| Jobs | The project's own jobs, same shape as the Jobs tab on the company page. |
Workflow
- Click a project row on a company's Projects tab, or a project name in a breadcrumb.
- The project opens on Form Submissions by default (the link target is
?tab=forms). - Click Jobs to see the project's jobs, or click View Response > on a submission row to open it.
Permissions and settings
Gates: the user must be a guest, plus Safety Forms → View (Form Submissions tab) and Jobs → View (Jobs tab) on the guest's role.
If the project is flagged internal, the guest only ever sees the Form Submissions tab -- the Jobs tab is dropped entirely for that project, regardless of the Jobs → View permission.
Related pages
Jobs (/guest/jobs, /guest/jobs/[id])
Where it is
/guest/jobs (the bare list URL) also immediately redirects to /guest/companies -- same
as /guest/projects, there is no standalone cross-company job list for a guest.
/guest/jobs/{id} is a single job's record, reached from a company's or project's Jobs
tab.
What it's for
A single job scoped to the guest: a header with the job number/name (and project number, if it has one) and two tabs, Form Submissions and RFIs.
Screenshot
No screenshot -- see the note at the top of this page.
Tabs and columns
| Tab | Contents |
|---|---|
| Form Submissions | Same shape as the Project Form Submissions tab, scoped to this job. |
| RFIs | RFIs raised on this job. Clicking a row opens that RFI directly (no intermediate flyout). There is no Create Request For Information button for a guest. |
The RFI list a guest sees is filtered to a single configured status -- Settings → System Settings → RFI Status → Customer Portal Status, which defaults to "None (show all)" if never set. Only RFIs currently at that exact status show up here. Because responding to an RFI auto-transitions it to a different status (see RFI detail below), a guest's own RFI can disappear from this list right after they respond to it -- the RFI detail page itself still opens by direct link, but the list row is gone on refresh. This is real behavior, not a hypothetical edge case.
Workflow
- Click a job row on a company's or project's Jobs tab.
- The job opens on Form Submissions by default (the link target is
?tab=safety-form). - Click RFIs to see the job's RFI list (filtered as noted above), or click a row to open that RFI.
Permissions and settings
Gates: the user must be a guest, plus Safety Forms → View (Form Submissions tab) and Request For Information → View (RFIs tab) on the guest's role.
Related pages
RFI detail (/guest/jobs/[id]/rfis/[rfiId])
Where it is
Click a row on a job's RFIs tab (/guest/jobs/{jobId}/rfis/{rfiId}?tab=overview).
What it's for
Lets a guest read the details of one Request For Information raised against the job they were given access to, and -- when the RFI is still awaiting a response -- submit that response. This is the one place in the guest portal where a guest can write data back into Appello, not just read it.
Screenshot
No screenshot -- see the note at the top of this page.
Controls and fields
The page has a single Overview tab -- the same RFI detail view staff see. A guest opens it via the record's Edit action to respond; the fields that appear are whatever the RFI data model and the guest role's field permissions expose, but the two that matter for a guest are:
| Field / Control | Required | Type | Effect |
|---|---|---|---|
| Response | Yes, to submit a response | Rich text | The guest's written answer to the RFI. Rendered read-only as formatted text plus any attached files once set; empty shows as "--". |
| Response file attachments | No | File upload(s) | Files the guest attaches alongside their response; shown in a small attachment grid under the response text once saved. |
Once a response exists, the detail view also shows who answered it and when (attributed to the guest's own user record) underneath the response text.
Workflow
- Open the RFI from the job's RFIs tab.
- Review the RFI's details (number, description, drawing reference if one is attached, due date, and so on) on the Overview tab.
- If the RFI has not been answered yet, use the record's edit action to open the response form, enter the Response text, optionally attach files, and save.
- On the first save that sets a response:
- The response is timestamped and attributed to the guest's own account.
- If the instance has a Responded Status configured (Settings → System Settings → RFI Status → Responded Status), the RFI's status is automatically changed to it.
- A notification (RFI response submitted) is sent to the internal user the RFI is assigned to.
- Editing the response text again after that does not re-stamp the response date or re-notify -- only the very first submission triggers the status change and notification.
This in-app response flow (signing in to the guest portal and editing the RFI record) is separate from Appello's no-login public RFI response link, which some RFIs also support for recipients who are not Appello users at all. That public flow is not part of the guest portal and is not covered on this page.
Permissions and settings
Gates: the user must be a guest, plus Request For Information → View to open the record at all. Whether the edit/response action is available depends on the guest role's Request For Information → Edit permission and on any field-level permission set for the Response field specifically (Settings → Roles → field permissions) -- this review did not find a guest-specific carve-out beyond the standard field-permission system, so what a guest can edit on this record is whatever their role's field permissions allow.
Related pages
Safety Inspection Forms (/guest/safety-inspection-forms)
Where it is
Reached indirectly: click View Response > on a row in a Form Submissions tab
(on a company, project, or job page). This opens
/guest/safety-inspection-forms/{safetyFormId}/{feedbackId} in a new browser tab.
A guest cannot browse safety forms themselves -- neither the safety-forms list nor an individual safety form's own detail page (with Form Submissions, Attached Jobs, and Details tabs) is reachable for a guest; both send them straight back to the guest portal. The only real guest page here is a single submitted response, which is what this section describes.
What it's for
Shows one submitted safety-form response in full -- the questions and the answers as submitted, any comments or acknowledgements recorded against it, and, if the form was resubmitted, the earlier version(s) in the same trail.
Screenshot
No screenshot -- see the note at the top of this page.
Contents
| Element | Description |
|---|---|
| Submission header | Safety form name, submitted-by, submission date. |
| Question/answer list | Every question on the form with the answer recorded for this submission. |
| Comments | Any answer-level comments left on the submission. |
| Revision trail | If the form has been resubmitted since, each prior version is listed alongside the current one, newest first. |
Workflow
- From a company's, project's, or job's Form Submissions tab, click **View Response
** on a submission row.
- The submission opens in a new tab at
/guest/safety-inspection-forms/{safetyFormId}/{feedbackId}, read-only.
Permissions and settings
Gate: Safety Forms → View on the guest's role (the same permission that shows the Form Submissions tabs that link here). There is no separate gate on the response page itself beyond the user being a guest.
Related pages
Profile (/guest/profile)
Where it is
Navbar (guest) → profile dropdown → Edit Profile, or directly at /guest/profile.
What it's for
Lets a guest see their own account details and change their password. It is not a general profile editor -- every field except the password is read-only.
Screenshot
No screenshot -- see the note at the top of this page.
Controls and fields
| Field / Control | Required | Type | Effect |
|---|---|---|---|
| First Name | -- | Text (disabled) | Display only; not editable by the guest. |
| Last Name | -- | Text (disabled) | Display only; not editable by the guest. |
| Email Address | -- | Text (disabled) | Display only; not editable by the guest. |
| Company | -- | Text (disabled) | The contact's current company name; display only. |
| Password Reset section | -- | Password fields (Show/Hide, generate/validate against the same policy as Reset password) | Lets the guest change their own password without an email link. |
Workflow
- Open Edit Profile from the guest navbar dropdown.
- Review the read-only account fields.
- To change the password, fill in the Password Reset section and save; a leave-page warning appears if there are unsaved changes.
- Cancelling or leaving without saving returns to
/guest.
Permissions and settings
Gate: the user must be a guest. No other permission applies -- every guest can reach their own profile and change their own password regardless of role.
Related pages
What a guest cannot do
Based on the gates described across the guest screens above, a guest user:
- Cannot open any page outside the guest portal -- every other page sends them back to it.
- Cannot use global search or see the notification bell -- both are hidden from the guest navbar.
- Cannot see Settings or Files in navigation, and has no access to instance configuration, roles, or user management.
- Cannot create, edit, archive, or delete Projects, Jobs, Companies, or Safety Form submissions -- every guest list (Projects, Jobs, Form Submissions) is rendered read-only.
- Cannot create a Request For Information -- the Create Request For Information button is hidden for guests; the only write access a guest has anywhere in the portal is responding to an existing RFI (see RFI detail).
- Cannot see companies, projects, or jobs beyond what was explicitly toggled on for their contact (see How a guest is invited) -- being a contact on a company does not by itself grant guest visibility into it.
- Cannot see RFIs outside the single "Customer Portal Status" configured for the instance, even on a job they otherwise have full access to.
- Cannot edit their own name, email, or company on their Profile page -- only their password.
- Cannot invite another guest, or change their own portal access -- both are Contact Settings-tab actions available only to staff with edit access to that Contact.
Related pages
- Contacts -- where a guest is invited and their portal access is managed
- Sign In, Password and PIN Reset, Invite Onboarding -- the sign-in and invite-link mechanics a guest shares with regular users
- Dropbox Sign E-Signature -- another page documented from source without live screenshots, for reference on that pattern