# Request form on your website

> The embed widget - a request form you place on your own website, so residents and occupants can report issues with no account and no login.

Source: https://app.assetlab.ca/docs/cmms/embed-widget

The embed widget puts an AssetLab request form directly on your own website - a town's "report an issue" page, a property manager's tenant site, an intranet. Visitors fill in a short form and it becomes a [work request](/docs/cmms/work-requests) in your organization: no account, no login, no AssetLab branding required. It is built for the public you serve - residents, occupants, visitors - the audience one step wider than the email-only reporters [email intake](/docs/cmms/email-intake) covers.

## How it works

The widget is a small snippet you paste into your site:

```html
<script src="https://app.assetlab.ca/embed.js" data-key="emb_..." async></script>
```

The form renders where the snippet sits, sized to fit, in your colors. It looks like the [requester portal](/docs/cmms/requester-portal)'s request form: where it is, the visitor's details, and what's wrong, side by side when there is room and stacked when there is not, with rooms picked from a searchable list. When a visitor submits:

| Form field | Becomes |
| --- | --- |
| Name and email | The requester on the request |
| Title | Request title |
| Details | Request description |
| Site, building, room or area, category, urgency | The request's associations and priority (each field optional, and only shown if you enable it) |
| Photo | An attachment on the request |

The submitter is matched against your existing [requesters](/docs/cmms/requester-portal) by email address; an unknown submitter gets a new requester record. The request lands in **Work Requests** as *Pending Review*, exactly like a portal or email submission, and your normal flow takes over: triage, conversations, approval or decline. The submitter gets a confirmation email immediately, and each staff reply in the request conversation is emailed to them - that is how you keep them in the loop.

> [!note] Widget submitters are unverified. Anyone can type any email address into a public form, so embedded submissions **never auto-approve** - they always wait for a human, even when auto-approval is on. A submitter whose email matches a requester with a linked account is the one exception, mirroring the email intake rule.

## Setting it up

Administrators manage embeds under **Settings → Embed Widget**:

1. **Create an embed** and name it for where it will live ("Town website", "Tenant portal").
2. **Add your website's address** under *Allowed websites* (e.g. `https://www.yourtown.ca`). This is required - browsers refuse to display the widget anywhere that is not on this list.
3. **Copy the snippet** and paste it into your site where the form should appear.
4. **Shape the form.** Toggle which fields visitors see - site, building and location, category, priority, photo - and set the defaults applied when a field is hidden or left blank. Categories feed [auto-assignment](/docs/cmms/work-requests) once a request is approved.
5. **Match your site.** Set the button, background, and text colors, corner rounding, and light/dark appearance (or let it follow the visitor's system setting). Your organization logo appears automatically if one is set. A live preview shows the result as you adjust it.

Each embed has an on/off toggle - turning it off blanks the widget everywhere instantly and is reversible. Deleting an embed never touches the requests it created.

### Display modes

The default snippet renders the form inline. Two attributes change that:

| Snippet | Behavior |
| --- | --- |
| `data-mode="popup" data-target=".report-button"` | Clicking any matching element on your page opens the form in a dialog |
| `data-mode="float" data-label="Report an issue"` | A floating button sits at the bottom-right corner of every page carrying the snippet |

If your site's content editor strips scripts, an `<iframe>` pointing at the widget address works as a fallback - the snippet is still the better experience because it auto-sizes the form.

## Privacy

The form shows a collection notice above the submit button explaining that the submitted information is used to review and complete the request. You can replace the standard wording with your own - municipal organizations typically point at their own privacy policy - in the embed's settings.

## Limits

- **30 requests per hour per organization** across all embeds. Submissions beyond that are refused with a "try again later" message - it protects your review queue if a public form is spammed.
- **One photo per request**, images only, 5 MB or under. Your team can attach more files afterwards.
- **Confirmation and conversation replies are the only automatic emails to the submitter.** Approving, declining, or completing the request does not notify them by itself - post a conversation reply when you want them to know the outcome.
- **Submitters have no status page.** The widget confirms and emails; it does not let a visitor browse their past requests. Someone who reports regularly is a candidate for a [portal](/docs/cmms/requester-portal) account.

## Good practices

- **Keep the form short.** Every field you toggle on costs completions. Name, email, title, details, and a photo is the sweet spot for public reporting; use a default site and category instead of asking.
- **Write the collection notice for your jurisdiction.** The standard wording is a floor, not legal advice.
- **Close the loop in the conversation.** Widget submitters can't see the app - a one-line reply ("crew scheduled for Tuesday") is what tells them their report worked.