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.
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 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 covers.
How it works
The widget is a small snippet you paste into your site:
<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'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 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.
Setting it up
Administrators manage embeds under Settings → Embed Widget:
- Create an embed and name it for where it will live ("Town website", "Tenant portal").
- 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. - Copy the snippet and paste it into your site where the form should appear.
- 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 once a request is approved.
- 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 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.