ReSOLVE Facilities
User
User
Manual
Complete guide to the multi-tenant request and operations management platform — every feature, screen and setting.
Complete guide to the multi-tenant request and operations management platform — every feature, screen and setting.
ReSOLVE Facilities is a multi-tenant platform for managing service requests, technical teams and maintenance operations. Built for condominiums, hotels, hospitals, schools, data centres and any organisation with units, sectors and field teams.
Each ReSOLVE customer — called a tenant — has its own isolated workspace: users, service categories, organisational units (sectors), infrastructure (properties / floors / rooms), assignment rules and request data. No tenant ever sees another tenant's data.
Within each tenant, users create requests (service orders): a water leak in a room, a broken piece of equipment, a transport to schedule, an event to prepare. Each request follows a lifecycle — Open → In progress → Resolved — with priority, resolution deadline (SLA), assignment to a unit and a responsible technician.
Before inviting the team, spend 15 minutes setting up units, infrastructure and categories. A well-configured tenant from day one cuts assignment errors and speeds up daily work.
Sign-up is self-service at app.resolve-facilities.com/signup. Every choice you make in this flow defines how your tenant is provisioned — from plan limits to the default category catalogue.
You need:
resolve-facilities.com/termos.html and /privacidade.html).no-reply@resolve-facilities.com with next steps.Creating the account runs an atomic server transaction that creates several data rows at once. The table below summarises what is loaded based on your choices:
| Choice | What is created / loaded |
|---|---|
| Organisation type | Initial category and subcategory catalogue tailored to the sector. For example, a hotel gets categories like "Rooms / Cleaning" and "Events"; a hospital gets "Biomedical maintenance" and "Clinical hygiene". |
| System language | The category catalogue above is loaded in the chosen language. Transactional emails (welcome, invitations, dunning) are also sent in this language. |
| Plan | Tenant limits: max users, max units, max requests per month. Features enabled: AI, SLAs, white-label, integrations (see chapter 19). |
| 14-day Trial | Creates the account with Starter limits (5 users, 1 unit, 1,000 requests) for 14 days. On day 15, if no paid plan has been activated, the account is suspended (it does not auto-downgrade to Free — moving to Free is an explicit choice). |
| Organisation name | Appears in invoices, emails, and on the Dashboard until you upload your own logo (white-label, Enterprise+). |
| Administrator name + email | The first user is created with role SYSTEM_ADMIN. You can invite more users later. |
| Default unit | A "General" unit is automatically created (rename it later) to receive requests until you configure specific sectors. |
At the end of the 14-day trial, the account is suspended and users lose access until they subscribe to a plan. Data is preserved but work stops. We recommend setting an alarm for day 12 and deciding in time.
The Custom plan is for organisations that don't fit the fixed tiers. When you pick Custom during sign-up, you go to a calculator where you specify:
The price is calculated in real time based on marginal per-user tiers (€4 for the first 199 users, €3.75 between 200 and 499, €3.50 above 500) multiplied by an organisational complexity factor (more units per user = more operational isolation = more support overhead). Includes AI, SLAs, white-label, email support and assisted onboarding.
Above 1,000 users, self-service sign-up is not available — email support@resolve-facilities.com and we will prepare a tailored quote.
If you were invited to an existing organisation, you receive an email from no-reply@resolve-facilities.com with the subject "You have been added to [Organisation] on ReSOLVE Facilities" and a "Sign in now" button. Clicking that button:
Your administrator sets the role (admin, supervisor, technician, user, resident) — you can request a role change directly from whoever invited you.
Access to the platform is at app.resolve-facilities.com. The flow has two steps (email first, password second) and supports multiple organisations per user.
If you forgot your password:
If the recovery link has expired or has already been used, you'll see a clear message — just repeat the request from "Forgot password".
The same email can belong to several organisations (for example, a technician servicing two condominiums). In that case, after login the Organisation picker appears:
The password is unique per user (not per organisation). If you change the password, it remains valid for every organisation you belong to.
ReSOLVE Facilities is a Progressive Web App (PWA). It is not in the Apple or Google stores — install it directly from the browser in a few seconds. Works like a native app: icon on the home screen, full-screen with no URL bar, push notifications.
app.resolve-facilities.com.Android is the most direct path: Chrome automatically detects that the app is installable and shows a prompt. If the prompt disappears or never showed up:
app.resolve-facilities.com.On iPads and Android tablets, the procedure is identical. On iPad, the Share bar is in the top-right of Safari, not in the bottom bar.
After installing and signing in for the first time, the browser asks if you want to allow notifications. Accept — notifications are key to receiving alerts about new requests, assignments and real-time messages.
On iPhone, push notifications only work if the app was installed on the home screen (steps above). On Safari opened as a web page, iOS does not allow push. If you don't receive notifications on iPhone, make sure you are opening the app from the home-screen icon and not from Safari.
To manage notifications after accepting, go to Account & Management → Notifications inside the app (chapter 10.3) or to the operating system settings (iPhone Settings / Android → Notifications → ReSOLVE).
The app keeps a copy of the data already loaded on the device, so you can keep consulting requests, assets and plans when the network drops — the typical case in basements, plant rooms and car parks. A bar at the top of the screen always tells you where your changes stand:
The queue covers the most common field actions: changing a request's status, writing a note, attaching a file, signing the service sheet, creating a request and sending a chat message.
The queue lives on the device: uninstalling the app or clearing the browser data before the network returns loses whatever was pending. Wait for Everything synced.
The Dashboard is the home page after sign-in. It shows the day's operational health at a glance: active requests, critical ones, overdue ones, distribution by category and team workload.
At the top a greeting adapts to the time of day (Good morning / Good afternoon / Good evening) followed by the organisation's logo. If you have an Enterprise+ plan and configured white-label (chapter 18), your own logo appears.
Shows the composition of active requests in a doughnut-style chart, with a dropdown to choose the grouping criterion:
Visible only to users with role ADMIN, SYSTEM_ADMIN or SUPERVISOR. A horizontal bar chart with the number of active requests per technician — useful to spot overload or imbalanced distribution.
For new organisations, a checklist of six steps appears to accelerate initial configuration:
You can Dismiss the checklist at any time — it does not block any feature. It reappears if manually restored.
The Requests screen is the operational hub: it lists every request you can see, filtered in eight tabs. Visibility depends on your role and the scope defined in Permissions (chapter 16).
| Tab | Shows |
|---|---|
| All | Every request visible to your user. |
| Assigned to me | Active requests where you are the assigned technician. |
| Open | Status Open and Delayed. |
| In progress | Status In progress (technician has started work). |
| Critical | Priority CRITICAL and still active. |
| Delayed | Past the SLA deadline (Growth+). |
| Resolved | Successfully closed. |
| Cancelled | Cancelled or rejected. |
Each request appears as a card with:
Two extras: orders generated by maintenance plans carry the Preventive badge (violet — chapter 22), and in the header you can switch between the card view and the condensed view (one line per request, 2-3× more items per screen). The choice is remembered per device and also exists on the Assets, Plans and Conversations lists.
The Export CSV button downloads all requests visible in the current tab in CSV format. Useful for external analysis (Excel, BI, accounting). Columns included:
Combining "Resolution time" and "SLA defined" in Excel or BI makes it easy to spot categories or units consistently missing deadlines — the basis for continuous-improvement conversations.
In the Requests header you can swap the list for the calendar view. Each day shows the requests with a scheduled date (Scheduled tag) and those whose SLA deadline falls on that day (Deadline tag), in the category colour. Whatever is filtered — tab, search, location, assignee and sector — applies to the calendar too.
Next to it sits the To schedule tray, with the requests that still have no date. Drag a request onto a day to schedule it, or back to the tray to remove the date; a tap without dragging opens the request. Only technical and management staff can drag, and past days are blocked.
The resolution deadline is born — or moves — with the scheduled date: rescheduling adjusts the deadline. While a request has no date, no countdown runs against the team.
Orders generated by maintenance plans follow two extra rules: they cannot be left without a date (the tray rejects them, in red) and they can only be rescheduled within their cycle — a monthly task due on 15 March accepts any day up to 14 April, and no further. Whenever the app refuses, it explains why.
A scheduled date that passes without the request being resolved rolls on its own to the next business day — the platform skips the organisation's configured weekend and its registered holidays. This automatic roll is silent and does not touch the SLA deadline: the clock counts from the start, and a late request stays late. Rescheduling by hand is different — that one adjusts the deadline and notifies everyone involved, as always.
The Reports menu produces a PDF with the operational picture of a period. Pick the range (this month, last 30 days, last 90 days or custom dates) and, if you want, filter by sector and by assignee before generating. The document carries the period indicators — requests created, resolved, pending and delayed, SLA compliance and median resolution time —, the breakdown by category, the evolution over the period, the list of pending requests and the totals per building and per sector.
The scope follows your role: an administrator sees the whole organisation, a supervisor sees their sector. The PDF header always states the period and the filters applied, so the document does not lose context once printed.
The report distinguishes two universes, and says so in the footer to avoid confusion: created counts requests opened in the period; resolved, median time and cost count the ones that closed in the period, even if they were opened earlier. That is the honest reading — work that closed in August counts for August, even if it started in July.
Beyond the classic indicators, the document carries the planned vs reactive split (preventive against corrective, the indicator that shows whether maintenance is gaining ground or firefighting), the cost of the period and a table by asset — number of requests, preventive/corrective mix, median time and cost — that answers "which piece of equipment is eating the team". The on-screen preview now also shows the evolution chart, which used to appear only in the PDF.
You choose what appears: before generating, a checklist switches each section of the document on or off — the choice is remembered in your browser. The pending table gains dedicated category and hold reason columns (filled for requests on hold; blank for the rest), and three pie charts summarise pending by reason, pending by category and resolved by category — the same category always keeps the same colour across both pies. In the period evolution, intake appears stacked by type (preventive below, corrective on top) with resolved as its own bar alongside — two universes, side by side, never added together.
The New Request screen gathers everything needed to open a service order. The form has five expandable sections — you can fill them in any order.
This is the first section of the form. You can attach a photo through:
After attaching a photo, the AI analysis button appears. When clicked:
AI analysis is available on the Starter, Growth, Enterprise and Custom plans. It is not included in Free.
The organisation can also switch AI analysis off in Request Options (chapter 24): the photo can still be attached — it stays as the request's photographic record — but the fields no longer fill themselves in.
Three hierarchical levels:
The location structure is defined in Admin → Infrastructure (chapter 13). If your organisation did not configure floors or rooms, those levels show as "N/A".
When the request is linked to a high-criticality asset (chapter 22), the priority arrives suggested as High — or Critical, if the equipment is stopped. It is a suggestion with a visible hint under the buttons: whoever opens the request can always change it, and once they do the platform stops suggesting.
Some categories carry extra fields adapted to the request type. They appear automatically when you pick the matching category:
The configuration of these fields is done per category in Admin → Categories (chapter 12).
If your organisation configured assignment rules (chapter 15), the request can be automatically assigned to a unit on submission — for example, all "Electrical" requests go to the "Maintenance" unit. If there is no rule, the request goes into "Awaiting assignment".
With the asset module active (chapter 22), the form shows the Scan equipment QR button: point the camera at the label and the request is linked to that asset, with the location filled in from its record. It is the fastest — and safest — way to raise a corrective right next to the machine, with no identification mistakes.
Labels from another organisation are ignored with a warning: the scanner only recognises assets from your own register.
Your organisation may have hidden some of these steps under Account & Management → Request Options — see chapter 24. If you cannot find the photo, QR scan, signature, labour, spare parts, failure codes, validation or attachments, that is where they are switched on.
Clicking a request card in the list opens the detail screen. This is where practically all the work happens: comments, attachments, status changes, reassignments, history.
| Section | Content |
|---|---|
| Header | Title, priority badge, status, SLA countdown (if applicable). |
| Information | Category, subcategory, description, attached photo, dynamic fields (transport, event, etc.). |
| Location | Property / floor / room. |
| Responsible unit | Assigned sector. "Transfer" button to reassign. |
| Technician | Avatar + technician name. Dropdown to reassign. |
| History | Chronological timeline: creation, status changes, reassignments, notes. Each entry shows who did what and when. |
| Notes and attachments | Field to add a note or attachment. Notes are visible to every authorised user. |
| Action buttons | Vary by role and current state (see below). |
Available actions depend on your role and the request's state. Summary:
| Action | Who can | When |
|---|---|---|
| Start | Assigned technician, Admin | Status = Open |
| Resolve | Assigned technician, Admin | Status = In progress |
| Reassign unit | Admin, Supervisor | Any active state |
| Reassign technician | Admin, Supervisor | Any active state |
| Cancel | Admin, request author | Active state |
| Delete | SYSTEM_ADMIN | Any state |
So the screen doesn't demand a click sequence nobody performs in practice, three links are automatic:
The assignee can be changed or removed only by sector administrators (Remove assignee in the assignment dialog). For every other profile the existing assignment is final — it stops two technicians from swapping mid-job.
The history is immutable — every status change, reassignment or note addition is logged with a timestamp and author. Useful for:
If the category has an SLA configured (Growth+ plans, see chapter 17), the header shows a badge with:
Requests that miss the deadline move to Delayed (visible in the "Delayed" tab) and count towards the Dashboard's "Delayed" KPI.
The Attachments section of the request accepts photos taken on the spot and files (PDF, images, documents) — before, during and after the intervention. They are stored privately and open through a temporary secure link.
The Service sheet collects the technician's and the client's signatures on screen (finger or stylus). Both are optional — you can close a request without signing — and they are printed on the request PDF, with the name and date. When you resolve a request the app offers to sign there and then; you can also collect the signature later, with the Sign sheet button.
Not all the time a request takes is the team's responsibility. The part ships from abroad and takes three weeks, the quote is waiting for approval, the contractor hasn't shown up. If the clock keeps running, the report ends up saying the team is slow when the problem is somewhere else.
In the request detail, the Put on hold button asks for a reason and an optional note. The reasons are the three defaults — awaiting parts, awaiting approval, awaiting third party — or the organisation's own list defined in Request Options (chapter 24), up to ten. From then on:
When you click Resume, the paused time is given back to the deadline: a request that waited 48 hours for a part gains 48 hours of effective deadline. Every hold and resume is recorded in the history, with who did it and for how long — the conversation with the client stops being about memory.
When you mark a request as Resolved, the platform opens a short dialog to capture what matters later:
The problem and cause lists come from the organisation's catalogue (section 22.14) and, when the request is linked to an asset, they arrive already filtered by that equipment's type. All fields are optional — whoever is in a hurry closes and moves on; whoever records gets, after a few months, the answer to "why does this equipment give us so much trouble".
On preventive orders this step does not appear: the record of the work is the plan's own procedure, and asking "problem and cause" of a planned task makes no sense.
Once resolved, the request awaits validation by whoever opened it, who confirms the work and may leave a rating. If the person who opened the request is also the one who carried it out, validation moves to the sector's administrator or supervisor — nobody validates their own work. With no answer within seven days, the platform validates automatically.
With the labour rate set (section 22.15), the hours become a labour cost, stored on the request at closing time. The detail then shows the intervention cost: labour plus the value of the parts consumed, minus the ones returned.
Your organisation may have hidden some of these steps under Account & Management → Request Options — see chapter 24. If you cannot find the photo, QR scan, signature, labour, spare parts, failure codes, validation or attachments, that is where they are switched on.
The Communication screen is the organisation's operational chat — real-time conversations between technicians, supervisors, teams and residents. Replaces WhatsApp and email for internal coordination.
You can send:
Messages arrive in real time (push notification, if authorised). Each conversation shows how many unread messages it has.
To create a new conversation:
The Account & Management screen bundles everything tied to the individual account: avatar, name, language, theme, notifications, privacy and sign-out. For users with administrative roles, it is also the entry point to the organisation's configuration menus.
Shows the current notification permission state:
The Test subscription button confirms that your device is properly registered. It shows the tail of the subscription endpoint.
On iPhone, push notifications only work if you installed the app on the home screen (see chapter 4). The Account & Management screen shows a specific warning if it detects you are using the app in Safari without having installed it.
Clicking Privacy policy opens the up-to-date document at resolve-facilities.com/privacidade.html in the chosen language. For GDPR requests (data access, export, deletion), email support@resolve-facilities.com.
The Sign out button at the bottom of the screen ends the current session. If "Keep me signed in" was ticked, it is cleared on this device as well.
In Account & Management → Calendar, the Get my link button creates a personal link you can subscribe to in your phone's calendar. Requests assigned to you that have a scheduled date then show up among your appointments and update themselves when the date changes or the work is done.
Phones refresh subscribed calendars every so often (typically hourly) — it is not instant.
It works like a password: anyone holding it sees your requests. Do not share it — and if it does leak, use Generate new link: the previous one stops working immediately.
The Team menu bundles all people management: invite users, assign roles and technical areas, manage multi-tenant membership. Accessible only to users with an administrative role.
If the email already belongs to a platform user (in other organisations), they get a "You have been added to [Organisation]" email letting them know a new organisation is available in the picker. If this is their first tenant, a new account is created and they get a welcome email.
Distinct from system roles (Admin/Supervisor/etc.), job functions describe the professional role: Electrician, Carpenter, Receptionist, Manager, etc. They help filter the team list and assign requests with more clarity.
To manage: Team → Job functions. Add, edit or remove entries at any time.
Technical areas are operational domains — Cleaning, Maintenance, IT, Security, etc. A user can belong to one or more areas. They enable:
Each area can have its own icon (picked from a Material Symbols library).
A user can belong to multiple organisations. In the team list, multi-tenant users are flagged with a badge. Each organisation sees only this user's role within the organisation itself — roles and data are not shared across tenants.
The CUSTOMER role (CLIENTE) is for people outside your internal team who need to interact with the platform — typically an end customer, a resident in a third-party-managed condominium, or an external partner. It's the gateway to the Customer Portal: a deliberately narrowed view of the app that keeps the customer focused on their own requests without exposing the organisation's internal structure.
When the invite is processed, the platform automatically creates a direct conversation between the customer and the organisation's SYSTEM_ADMIN. It appears immediately in Communication with the administrator's name, giving the customer a guaranteed support channel without having to search for one.
Operational permissions (create, start, resolve own and assigned requests) are identical. What sets the Customer apart is the communication filter — they don't see the team or collective groups, only their requests and the direct channel with the admin. Use USER (UTILIZADOR) for internal non-technical staff; use CLIENTE for third parties.
Whoever holds the SYSTEM_ADMIN role manages each member's lifecycle from their record in Team:
If the member had access to the maintenance module, deactivating or removing them also frees that seat (chapter 22.1).
Categories define the types of request your organisation processes. They are initially loaded based on the organisation type picked at sign-up — and they are yours: manage subcategories, hide and delete any of them, including the ones loaded by default. Only the name and icon of the built-in ones stay fixed: the internal identifier derives from the original name and shows up in imports and rules — a new name on top of an old identifier would confuse.
Each category can enable extra fields in the request form (see chapter 7.5):
You can tie a category to a default unit. When a user creates a request in that category, it is automatically assigned to the unit. See chapter 15 for finer multi-condition rules.
Deleting a category with active requests is blocked — resolve or reclassify those first. With history only, it can be deleted, built-in ones included; old requests keep the name they were filed under, which is correct history.
Infrastructure defines the physical hierarchy where requests happen. The more detailed it is, the more precise the records and the more useful the location-based analyses.
Each property can store latitude, longitude and altitude. While editing, the Capture GPS position button reads the device's own position (handy when you are on site) and shows the accuracy obtained; alternatively you type the coordinates in. Open in map confirms the point before saving.
From the list, View on map opens every property on a single map, with the active filters applied; a note tells you how many were left out for having no coordinates. The same fields exist on assets (chapter 22.3) — that is what lets you send a crew to a substation or a pumping station with no useful street address.
Deleting a building, a floor or a room has consequences outside this screen — there are assets, maintenance plans and spare part links pointing at that space. So, before you confirm, the platform counts the impact and shows it: how many floors and rooms go down with it, and how many assets, plans and links lose that location.
On confirmation: the floors and rooms of the deleted space go with it, and the assets that were there are left without a location — they do not point at a ghost space. Assets, plans and request history are not deleted. Old requests keep the place name exactly as it was on the day of the intervention, because that is history and should not change.
Units are the teams / sectors that receive requests. Every request is assigned to a unit. The number of units is capped by the plan (1 on Free and Starter, 3 on Growth, 10 on Enterprise, configurable on Custom).
In Admin → Units:
Deleting a unit that has assigned requests requires confirmation — the requests move back to "Awaiting assignment" and you must reassign them manually.
Free: 1 unit · Starter: 1 unit · Growth: 3 units · Enterprise: 10 units · Custom: tailored (minimum 3, always less than the number of users).
Rules automate the routing of requests to units, removing the manual step and cutting the time to the technician's first touch.
Each rule defines: "When a request has [condition], assign to unit [X]". Supported conditions:
Rules are evaluated in order (top-down). The first match wins; the rest are ignored for that request. You can drag to reorder.
Put a "Generic → General unit" rule at the bottom of the list to make sure no request ends up orphaned. The earlier rules catch the specific cases; the fallback catches the rest.
The permissions matrix defines what each role can do: create, view, edit, change state, delete, transfer, assign and manage configuration.
| Role | Who they typically are |
|---|---|
| SYSTEM_ADMIN | Primary administrator of the organisation. Full control over the tenant. |
| ADMIN | Delegated administrator. Operational configuration. |
| SUPERVISOR | Team manager. Distributes requests, monitors SLAs. |
| TECNICO | Executes assigned requests. |
| AUXILIAR | Technical support, without responsibility for assigned requests. |
| UTILIZADOR | Creates requests, sees their own. |
| MORADOR | Creates requests in a condominium context. |
| CLIENTE | External customer. Same operational permissions as UTILIZADOR but communication limited to the SYSTEM_ADMIN — see chapter 11.5. |
Each permission has a scope:
The Admin → Permissions screen shows the full matrix read-only — now including the Modules group (Assets, Maintenance Plans and Condominium Portal management, applicable in organisations with the respective module). The Access Stats and Dashboards permission controls the Reports screen and the backoffice Indicators Panel. Changes are centrally managed by the ReSOLVE team — to request adjustments to your organisation's permission profile, contact support@resolve-facilities.com.
Two areas follow fixed platform rules, identical for every organisation: the request lifecycle (who starts, resolves, transfers, cancels or deletes follows an internal matrix by role, scope and ownership — the sections above) and certain fixed-role areas: the Backoffice and Billing belong to the System Admin, and validating a request closed by the person who opened it falls to the sector's administrator or supervisor. These rules do not appear as switches because they are not configurable.
SLAs (Service Level Agreements) define the maximum resolution time by category and priority. They let you measure operational performance, flag delayed requests and give customers visibility on the expected response time.
For each category you set two values:
Once configured:
Custom SLAs are included on the Growth, Enterprise and Custom plans. On Free and Starter, requests have no SLA and the "Delayed" tab is hidden.
White-label lets you customise the platform's look with your organisation's logo and primary colour — useful for premium condominiums, hotels, hospitals and any customer that wants to project their brand to end users.
White-label changes apply immediately to every user in the organisation — no need to sign out / in. The Reset button restores the default ReSOLVE logo and colour.
White-label is included on the Enterprise and Custom plans. On Free, Starter and Growth, this menu shows only an upgrade prompt.
All the organisation's financial management is concentrated in Account & Management → Billing: current plan, plan changes, payment method, invoice history and refunds.
| Free | Starter | Growth | Enterprise | Custom | |
|---|---|---|---|---|---|
| Monthly price (EUR) | €0 | €19 | €109 | €439 | variable |
| Annual price (EUR) | €0 | €190 | €1,090 | €4,390 | variable |
| Max users | 3 | 5 | 25 | 100 | tailored |
| Max units | 1 | 1 | 3 | 10 | tailored |
| Requests / month | 20 | 1,000 | unlimited | unlimited | unlimited |
| AI suggestions (Gemini) | — | ✓ | ✓ | ✓ | ✓ |
| Push notifications | ✓ | ✓ | ✓ | ✓ | ✓ |
| Custom SLAs | — | — | ✓ | ✓ | ✓ |
| White-label | — | — | — | ✓ | ✓ |
| Assisted onboarding | — | — | — | ✓ | ✓ |
| Assets and Preventive module (add-on) | — | — | +€250/month | +€850/month | +€10/user |
| Support | Community |
Annual billing gives you roughly 2 months free compared to monthly (€190 vs €228 annual on Starter, for instance). The cycle is chosen at subscription time and can be changed later (chapter 19.2).
In Account & Management → Billing, click Change plan. The plan table appears with clickable cards.
The Manage billing button opens Stripe's secure portal — outside our platform — where you can:
The "Invoice history" table shows the last 12 charges, with:
Refunded invoices (total or partial) appear with a clear badge, avoiding confusion with paid invoices.
The trial is an explicit choice at sign-up: it grants 14 days with Starter limits (5 users, 1 unit, 1,000 requests, AI on). On day 15:
The trial does not auto-migrate to Free at the end. Free is an explicit choice made at sign-up — those who want Free pick Free from the start. Those who picked Trial made a commitment to evaluate the paid product.
On top of the base plan, the organisation can activate additional modules on the same subscription. The first one available is Asset Management and Preventive Maintenance (chapter 22):
To activate: Account & Management → Billing → Add-ons → Activate module (requires an active subscription). In the plan selector, the chosen module size steers the compatible plans: 25 users fits any Growth+ plan; 100 requires Enterprise or Custom; a custom size only exists on Custom. The module switches on in seconds; the prorated amount for the current period lands on the next invoice (Stripe proration — no immediate charge). To remove it, use Remove module on the same card: access switches off immediately and the prorated credit lands on the next invoice. Data is never deleted — when you reactivate, everything comes back as it was.
Organisations with special terms can have the module activated directly by the ReSOLVE team — in that case the card shows the Offer badge, with no charge and no removal button.
The platform is translated into four languages: Portuguese, English, French and Spanish. The change is instant and propagates across the whole app.
There are three places where the language selector appears:
When a user accesses the site for the first time (with no stored preference), the platform tries to detect the browser language. If it is one of the four supported, it is used; otherwise it falls back to English.
Push notifications alert you to important events even when the app is closed — assigned requests, new messages, critical status changes.
Each person controls what they receive in Account & Management → Notifications: push in the browser and in the installed app, chat message notifications and email alerts — three independent switches.
To change the permission after accepting/rejecting:
Repeating the warning from chapter 4: on iPhone, without "Add to Home Screen" in Safari, there are no push notifications. It is an iOS restriction, not ours. Install the app on the home screen before accepting notifications.
Add-on module that brings equipment registration with QR labels, planned preventive maintenance and spare parts management to the platform: plans automatically generate work orders, with a step-by-step procedure and non-conformity detection. Managed in Account & Management → Asset Management.
The module is a paid add-on on top of the base plan (chapter 19.6): Growth +€250/month, Enterprise +€850/month, Custom +€10/user/month up to 100 seats (€9 above) (annual billing with ~2 months free). Activate it in Account & Management → Billing → Add-ons; it requires an active subscription on a Growth or higher plan. When you remove it, the data is kept — reading stays available, creating and editing are blocked — and reactivating brings everything back as it was.
The size of the module is independent from the base plan: an organisation with 100 users does not have to pay for 100 in the maintenance module. You pick the size in Billing and then grant access person by person, in Team → member record → Maintenance, where the counter reads "X of Y seats assigned". With no free seats the assignment is refused — increase the module size or take the access away from someone else. People without a seat keep using the platform normally; they simply do not see assets, plans or preventive orders.
Before registering assets, define the catalogue in Asset Management → Types and Families — for example, the HVAC type with the Chillers, AHUs and Splits families. Types feed the filters, the groupings and the scope of preventive plans. A type with linked assets or plans cannot be deleted (update them first).
Renaming a family is safe: the platform propagates the new name, in the same operation, to the assets in that family, to the maintenance plans scoped to the family and to the parts linked by family — and confirms on screen how many records it updated. Without that, a simple name fix would leave plans generating nothing and parts vanishing from the asset detail, silently.
Each asset has: name, type and family, location (property / floor / room), responsible sector, manufacturer, model, serial number, purchase and warranty dates, criticality (low / medium / high), notes and a photo (stored privately — only members of the organisation can see it). The state follows the lifecycle:
The list has search, filters (state, criticality, property), cascading groupings (type → family, location → floor, state) and a condensed view. An asset with linked requests cannot be deleted — set its state to Decommissioned, which preserves the history. Deleting an asset also deletes that asset's specific preventive plans.
Each record also stores GPS coordinates with altitude (captured on site or typed in, with View on map to confirm) and files — manuals, wiring diagrams, certificates, photos of the nameplate —, stored privately and opened through a temporary secure link. From the asset list, View on map shows every asset that has coordinates.
Labels come in two formats, chosen when printing: an A4 sheet with 21 labels per page (63.5×38.1 mm stickers, Avery L7160 type) or a 50×30 mm label, one per page, in series, for roll printers. Both carry the QR code, the asset code, the description and the organisation logo.
Generate sticker labels as a PDF (one per asset, with QR code and identification) and apply them to the equipment. Any team member points the phone camera at the QR — it opens the asset sheet directly, with the intervention history and the plans. From the sheet, the Create request button opens a corrective request already linked to the asset and with the location pre-filled.
In Asset Management → Assets → Import, download the CSV template (it includes a guidance row per column), fill it in and import hundreds of assets at once. Validation is row by row — a row with an error does not block the rest, and a second click on Import only retries the rows that failed. An equivalent importer exists for maintenance plans.
A plan defines what, where, when and how:
Plan cards show the trigger ("Every 250 hours or 6 months at most"), the next date when there is one and the number of tasks; clicking opens read-only, the pencil edits. Editing the procedure does not change orders already generated — each order keeps its own copy.
A plan whose scope is a single asset can be duplicated to several assets at once, and the One-off request button raises an order for one asset in scope without touching the plan's calendar (useful for an out-of-cycle job).
A meter is a quantity read on an asset over time. You create it on the asset record, under Meters and readings, with a type, a name and a unit. There are two behaviours:
Readings arrive two ways. By hand, with the Record reading button on the asset record — in practice, by scanning the equipment's QR label with the phone, which opens the right record straight away. Or through the procedure: a measurement task in the plan can be linked to a meter and, when the technician fills it in while carrying out the order, the value goes into the asset's series on its own. That is the loop that matters — the 250-hour service records the hours as it is performed, and that reading is what brings on the next one.
Any team member with module access can record readings; creating and deleting meters is for administrators. Mistakes are corrected with a new reading and a note (the recent readings open on the row itself); deleting a wrong reading is an administrator action.
The first time it runs, the plan stores the current reading as its starting mark and generates nothing — adopting a plan on a generator with 12,230 h does not flood your pending list with retroactive services. From then on it raises the order when current reading − reading at the last trigger ≥ interval. A large jump in the reading produces one order, not several overdue ones. And since an idle asset never accumulates hours, the plan accepts a calendar ceiling: 250 hours or 6 months at most, whichever comes first.
On broad scopes the plan editor tells you how many assets in scope actually have that meter ("3 of 5") — the others are simply left out, with no error. On parameter meters, the asset record shows which plans are watching them and with what threshold.
Every day the platform generates the due orders as regular requests with the Preventive badge — they enter the usual flow (assignment, SLA, chat, reports). Calendar plans are processed at 05:00 and meter-based plans at 05:10 (UTC); condition-based plans do not wait for the next day — the order appears as soon as a reading breaches the threshold. Each sector gets one push notification and one email a day, summarising everything generated for it, instead of one alert per order. Managers need not wait for the small hours either: the Generate now button on the plans screen runs the generator on the spot. On the request detail, the technician runs the procedure task by task; answers can be saved at any time, without changing the request's status.
If an inspection records Degraded / Failure, or a question is answered No, the platform offers to immediately create a corrective request linked to the same asset — the automatic bridge between preventive and corrective work.
A stopped plan (module deactivated, plan inactive) does not pile up overdue orders: when it resumes, it generates one catch-up order and skips to the next future date.
A recurring task should not fill the pending list with duplicates: when the next cycle appears, the previous order that never left Open is closed as cancelled, with a "not carried out within its period" note in the history. Orders the team actually started (they went through In progress) are spared — those stay open, because there is work to record. The sector's daily email states how many were closed this way.
On plans with a Legal basis (22.6), an overdue order never closes itself — a regulatory duty would otherwise be dropped without a trace. The order stays open, marked § Legal on the plan card, the request and the calendar, and the administrators get a daily alert until it is carried out. On completion, the app reminds you to attach the inspection certificate or report.
Besides the orders, the module watches four things for you and warns whoever needs to know:
The module includes warehouse management for spare parts — the material consumed during interventions: filters, belts, bearings, lamps, seals. You will find it under Assets → Parts, available to anyone holding a seat in the module (section 22.1).
One rule governs everything else: stock is never typed in by hand. The quantity you see is always the result of recorded movements — entries, usage, adjustments, returns and swaps. That is what lets you answer, months later, "where did those 12 filters go?".
SPR-…) — physical existence comes in the next step.There are two manual movements, with deliberately different permissions:
The part's history lists every movement newest first, with date, user, quantity, note and the linked request when there is one. It is immutable: a wrong posting is neither deleted nor rewritten — it is corrected with an adjustment (or, if it was usage on a work order, with the return described in 22.12).
Every part has its own QR code, in the same two formats as assets: an A4 sheet of 21 labels or a 50×30 mm label for roll printers (section 22.4). Stick the label on the shelf or the box: pointing a phone camera at it opens the part record with the current stock in plain sight — the fastest way to check quantities during a count.
When usage or an adjustment makes stock drop below the minimum, the sector responsible for the request — or the administrators, when the movement did not come from a request — receives a push notification and an email with the current quantity and the defined minimum.
The alert fires at the moment it crosses the threshold and does not repeat while stock stays low, so it never floods the team's phones. It re-arms on its own as soon as an entry brings the level back above the minimum.
Material consumed is recorded inside the work order, under Spare parts used. Each record deducts stock on the spot, lands in the request's history and in the part's, and appears on the intervention's PDF report — closing the loop between maintenance and the warehouse.
So that nobody has to hunt through a list of hundreds, the platform filters parts by the links defined on the part record. A part can be linked, non-exclusively, to:
A part with no links is treated as universal and always appears. On the asset record, the Compatible parts section shows the reverse view: which parts exist for that equipment, and with what stock.
If you ask for more than exists, the record is refused and the message states how much is available — stock never goes negative. Closed orders (resolved, cancelled or rejected) accept no new records.
Mistakes happen: the wrong part, twice the quantity, the wrong order. Instead of touching stock by hand, remove the record on the order itself.
The original record does not disappear — it stays visible, with the return beside it, in both the request's and the part's history. That is deliberate: whoever audits later sees what happened rather than a gap. Each usage can be returned only once, and returning requires the order to still be open.
Some equipment is not repaired in place: the faulty unit is swapped for a standby one and the repair happens later, on the bench or at the supplier. A UPS, a pump, a motor. The platform handles this without inventing a new entity.
A reserve unit is a normal asset, with its own record, QR code, history and plans — simply linked to a part as its reserve. That way, when it enters service it already carries everything worth knowing about it. Each asset can be the reserve of only one part.
In a single step the reserve becomes Active and inherits the location and responsible sector of the equipment it replaced — it takes its place for all purposes. The reserve link disappears (it is no longer in the warehouse) and the movement is recorded in the part's history with both units identified.
A preventive plan pointed at that particular asset is suspended along with it and does not migrate to the reserve unit — the platform cannot guess whether the plan followed the equipment or the place. If maintenance must continue, create the plan for the reserve or, better, use type, family or location scopes (section 22.6): those cover the reserve automatically, with no intervention.
A free-text history does not answer "why does this break". Two short lists do. In Asset Management › Failure codes, the administrator keeps the organisation's catalogue in two tabs: Problems (the symptom) and Causes (the root).
Codes are picked when resolving a request (section 8.7). On preventive orders with a non-conformity, the problem "Inspection non-conformity" comes pre-selected.
For the platform to answer "how much does this equipment cost to keep", two numbers are missing that only the organisation knows:
A single rate is fine to start, but not enough for a quote: a helper doesn't cost the same as a specialist, and a Sunday doesn't cost the same as a Tuesday morning. In Account & Management › Labour Costs (administrators only) you set, on one screen:
When resolving a request — or at any time, from the cost block — you record who worked, how many people, how many hours and in which period. Several lines are allowed: John did 2 normal hours, Peter 3 hours on Saturday. The period is suggested from the date and the working hours, and is always editable — the platform suggests, it doesn't impose.
The price is computed on the server and stored on each line as a snapshot: changing a rate tomorrow does not rewrite the cost of an intervention closed yesterday. With no rate set, the time is still recorded and the cost stays at zero — hours remain useful information.
From there everything computes itself: each part consumption stores the price of the moment (a price rise tomorrow does not rewrite yesterday's history), a return reverses exactly the value that left, and the asset detail shows the accumulated maintenance cost. The performance report carries the cost of the period.
Money is sensitive: it reveals what each person costs. So it has a permission of its own — See costs and values, in the Security and Governance matrix — on by default for admins and supervisors, off for technicians, helpers, users, residents and clients.
Without it no value shows at all: not on screen, not in the report, not in exports, not in PDFs. And it isn't just the screen hiding it — the database itself refuses cost queries, so the value never reaches the device. What stays visible is the time: who worked, how many hours, how many people and in what period. That is the record of the work, and the technician needs it.
Parts are recorded during the job, as they are used. Labour is recorded at the end: when resolving a request, the platform asks for the work carried out before collecting the signature. That makes sense — only at the end do you know how long it took.
Anyone offline can still resolve and record the hours later: the window stays open until the sheet is signed. Once signed, recorded work can no longer be changed — a signed sheet is worth exactly what it says.
It is the same sheet; what changes is who prints it. A technician downloads it with materials and labour but no values — it is what the client signs. A sector or system administrator downloads the same sheet priced, with labour and parts subtotals and the total, ready to attach to an invoice.
This is not a general ledger: there are no cost centres, no depreciation, no ERP integration. It is the operating cost per intervention and per piece of equipment — the number that decides between repairing again or replacing.
On the Assets and Spare parts screens, the Export CSV button downloads whatever is filtered on screen — the same filters you are looking at, not the whole database.
The assets file uses exactly the columns of the import template (section 22.5). That enables the full loop: export, fix dozens of rows with the comfort of a spreadsheet, and import again. The parts file carries stock, minimum, storage location and unit cost with the organisation's currency.
The files open directly in Excel, Numbers or Google Sheets (UTF-8, semicolon separator). And they answer, without promises, the question "what if one day I want to take my data with me?".
The official channel between management and residents: notices, meetings with automatic reminders, minutes and documents — on each resident's phone, without informal messaging groups.
The portal switches on automatically for organisations created with the Condominium type (chapter 2) — it is included in the plan, at no extra cost. For other organisation types, contact support.
In Account & Management → Condominium, four tabs:
Each publication has a scope: general (the whole condominium) or a specific building — each resident only sees what concerns them. Accepted files: PDF, images, Word (.docx) and Excel (.xlsx), up to 10 MB, stored privately and opened via a temporary secure link.
Residents get a Condominium entry in the main navigation, in read-only mode: they browse the notices, meetings, minutes and documents of the general scope and of their building, and download the files securely. (Creating maintenance requests stays in the normal flow — chapter 7.)
The day before each meeting (around 08:00), the covered residents receive a push notification and an email with the title, date, time and place. If the meeting is postponed, the reminder automatically re-arms for the day before the new date.
Meetings created after the day-before send has already gone out (for example, today for tomorrow morning) may not get an automatic reminder — in that case, publish a notice as well.
Each organisation chooses what appears in the creation form and during treatment. Nine switches plus your own on-hold reasons; everything on by default. Nothing changes until you switch something off.
Under Account & Management → Request Options. Only the organisation's System Admin sees this screen. Choices apply organisation-wide and take effect immediately for every user.
All switches start on. An organisation that never opens this screen works exactly as before — switching something off is an explicit decision, and always reversible.
Asset QR scan and Spare parts appear disabled, with the reason shown, in organisations without the Assets & Preventive Maintenance module. AI photo analysis appears locked on plans without AI Suggestions.
Hiding removes only the ability to add. Anything already recorded stays visible: logged hours, consumed parts, attachments, signatures and decided validations remain on the request and in reports. A switch never deletes history.
When completing a request, disabled steps are simply skipped. With everything off, resolving becomes a single click.
With signature off, the labour sheet is no longer sealed by the signature but by the requester's validation — hours stay editable until that moment.
On the same screen, the organisation defines its own "On hold" reasons — up to ten. Left untouched, the three defaults apply and are translated automatically into any language; once edited, the list becomes the exact text you write, and that is the list technicians see when pausing a request (chapter 8.6). Restore defaults goes back at any time. Requests already on hold keep the reason they were paused with.
A desk workspace for whoever administers the organisation: dense tables, bulk uploads and queries, over the same data as the app — not a second database.
The app was designed for the phone — excellent in the field, slow for the office work where two hundred rows get corrected. The Backoffice is the answer: same tenant, same data, same permissions, in a large-screen format.
Enter via Account & Management → Backoffice, the desktop sidebar item, or the direct address /backoffice. Reserved for the active organisation's System Admin; any other role that tries the address gets a restricted-access notice.
Menus are numbered, as in a classic ERP. Each node only appears to whoever holds the matching permission and, in group 3, only with the Assets module contracted.
| Group | Nodes |
|---|---|
| 1 — Master Tables | Categories & SLA · Sectors · Infrastructure · Technical Areas · Functions & Rates · Failure Codes · SLAs & Routing · Holidays & Calendar |
| 2 — Users | Team — grid, invitations and bulk upload |
| 3 — Assets & Maintenance | Asset Types · Assets · Maintenance Plans · Spare Parts |
| 4 — Queries | KPI Panel · Requests (Query) |
Every listing shares the same behaviour: global search, per-column filtering, sorting by any header, choice of visible columns (remembered per user) and CSV export of what is filtered — not just what fits on screen.
Editing happens in a side drawer. Richer entities — maintenance plans, assets, spare parts — carry a button that opens the app's full editor, where every field lives.
The Backoffice honours exactly the same rules as the app: whoever cannot see costs does not see them here, and whoever cannot manage a table does not find it in the tree.
Seven tables accept CSV upload: sectors, technical areas, job functions, categories, failure codes, infrastructure and spare parts. Assets, asset types, plans and users have their own importers, already in place.
Each importer starts by downloading a template with the right columns. The file is validated row by row before saving: errors are shown with the row number, and nothing is imported while errors remain.
KPI Panel repeats the indicators and charts from the reports, with the same periods. Requests (Query) is a dense grid of every request — active and closed on one timeline, sorted by creation date — with cascading filters and a link to each detail.
It was designed for the computer. It works on the phone — the tree becomes a drawer and grids scroll sideways — but volume work is done sitting down.
Definitions of the main terms used in this platform and in this manual.
The most common doubts from new users.
Make sure you opened the app from the home-screen icon, not from Safari. If you haven't installed it yet, go to chapter 4 and follow the "Add to Home Screen" steps. iOS does not allow push notifications without that installation.
On the login screen, click Forgot password, enter your email and follow the link you receive. The link is time-limited — if expired, just repeat the request.
Yes. After login, the organisation picker is shown (chapter 3.3). The role may be different in each organisation (e.g. admin in one, technician in another).
In Account & Management → Billing, in the history table, click the "PDF" link on each invoice. Alternatively, open the Stripe Portal (Manage billing) for access to every historical invoice.
Self-service downgrades are blocked. Cancel the current subscription (stays active until the end of the paid cycle) and subscribe to the lower plan afterwards, or contact support@resolve-facilities.com for support.
The initial catalogue was loaded based on the organisation type picked at sign-up. You can edit freely: add, rename, delete categories and subcategories in Admin → Categories (chapter 12).
GDPR requests should be submitted in writing to support@resolve-facilities.com. The organisation's administrator can delete users in Team; for full deletion of the tenant and its data, a formal request is required.
See chapter 19.1 (Plan comparison). Summary: Free €0, Starter €19/mo, Growth €109/mo, Enterprise €439/mo, Custom variable. Billing in EUR, processed by Stripe.
No — we sell exclusively in EUR. Stripe may auto-convert at the customer's card depending on the issuing bank, but invoices are issued in EUR.
For any operational doubts, technical issues, suggestions or formal data-protection requests, get in touch. We respond during business hours (Mon–Fri, 9 am–6 pm Lisbon time) and critical requests are prioritised.
© 2026 ReSOLVE Facilities. All rights reserved.
This manual describes the current version of the platform. Features and screens may evolve.