Maintenance and recurring tasks

Two modules cover the operational work of keeping a property running. Maintenance handles one-off requests (a tenant reports a leaking tap). Recurring tasks handle scheduled work (quarterly fire-alarm inspection, monthly cleaning visit).

Maintenance requests

A maintenance request records an issue on a property or one of its units, usually after a tenant reports it to you.

The flow

1. Report: A team member opens Maintenance → New request and records the issue: the property, the unit if it applies, a title, a description and a priority. A resident can also report one themselves if you have the resident portal on, in which case it waits for your approval before it becomes work. See Requests from residents.
2. Assign: The request appears in the maintenance list. Assign it to an in-house technician or to a vendor, either by naming a person or by pointing it at a role.
3. Resolve: The technician marks the work done and attaches completion proof, such as before and after photos.
4. Review and close: The request runs through the approval steps below. Closing it records the total cost against the request.

The default approval workflow

Once the technician finishes, the request moves through a four-step approval chain (customizable in Settings → Configuration → Workflows → Maintenance):

1. Operator Action: the technician marks the work complete and attaches completion proof (photos/videos).
2. PM Review: the Property Manager reviews the work, attaches the invoices, and enters the total cost (decimals accepted, e.g. 1,250.75).
3. Accountant Review: the accountant verifies the invoices against the cost, optionally attaches an accounting statement, and approves or returns the request to an earlier step with a note.
4. PM Confirmation: the Property Manager confirms the statement matches what was uploaded. Completing this step closes the request and records the total cost against it.

Closing a request does not create an expense entry for you. If you want the cost in your books, record it under Expenses.

Any reviewer can Return the request to any earlier step with a reason. The assignee of that step is notified and the history timeline records the round-trip.

Documents and the audit trail

Every upload appears in three places on the request page, each with a different job:

• Task history (timeline): each completed step's entry lists what was uploaded there, prefixed with the slot name (e.g. "Invoices · march.pdf"). Reviewers see earlier steps' files immediately: the accountant sees the PM's invoices before approving.
• Workflow documents, the live, organized view: one row per step's upload slot for the current cycle. When a step was returned and re-completed, the superseded files stay available under Previous versions, so you can see exactly what changed across decline rounds.
• Evidence & notes: the permanent record, grouped by cycle (CYCLE #1, CYCLE #2, …). Reopening a request starts a new cycle; earlier cycles' evidence stays here.

Deleting media (admins)

Admins can permanently delete any uploaded file or note, including on closed requests (e.g. removing a wrong or sensitive upload). Use the trash icon on an evidence tile or a workflow document. Deletion removes the file from the request, the document archive, and storage, and cannot be undone.

Notifications

Each step transition fires inbox notifications to the relevant roles. The default workflow notifies the assignee on assignment and the coordinator on completion. Workspace admins can adjust which role gets notified at each step. See Workflows and approvals.

Recurring tasks

A recurring task template describes work that needs to happen on a schedule: "Inspect the fire alarms in Al-Olaya Tower every 90 days." The template auto-generates an actual task instance each time the schedule fires, assigned to whomever the template says.

Setting up a template

Open Recurring → New template. The form walks through four steps and shows a summary before you save:

1. Basics: property, unit (or property-wide), task title and description.
2. Schedule: the first occurrence date, how often it repeats (every N days, weeks, months or years), when it stops repeating, and when reminders go out. The next three dates appear under the fields, so you see the real schedule before saving.
3. Assignment: who carries out the task, a role or a specific person. This step disappears entirely when the Team module is off for the workspace.
4. Contract & renewal: optional. The service contract's amount, notes and document, plus the option to track when it expires.

Save. The first instance generates at the next scheduled date.

Repeating until a date, or forever

A recurring task can repeat forever or until a date. Forever is the default, and it is what every template you already set up does, so nothing has changed underneath you.

Repeats until on the Schedule step starts on Never. Switch it to On a date and pick the day the series stops. The date is included: "repeats until 30 June 2027" means the 30 June visit still happens and the one after it does not. Set it back to Never and the task repeats with no end again.

You can change your mind whenever you like. Shortening a schedule removes the tasks that were already scheduled past the new date, and extending it puts them back. A task somebody has already started work on is kept either way, so a date change never destroys an approval that is halfway through.

An end date in the past is allowed and saves without a warning. It is how you record an agreement that has already finished.

The contract expiry date suggests an end date. Fill in Contract expiry date on the Contract & renewal step and Repeats until switches to that same date, because the usual reason a visit schedule ends is that the agreement paying for it ended. It is a suggestion and not a rule. It only fills a field you have left alone, so it never overwrites a date you picked yourself, and you can change it or set it back to Never afterwards. Nothing rewrites it later, on that save or any save after it.

Both fields are independent. Repeats until is always on the Schedule step, whether or not you are tracking a contract, because when the work stops is a fact about the schedule.

Deciding a contract renewal

When the expiry date approaches, a renewal task asks one question: renew, or end it. What you answer also moves the schedule.

A renewal task is a decision, not a visit, so it does not go through the recurring-task workflow's steps. Open it from Tasks (it is listed under Contract Lifecycle as a service contract renewal) and choose Decide. It is decided by someone with the Manage recurring tasks permission.

• End contract stops the series on the contract's expiry date, not on the day you decide. Deciding in October that you will not renew an agreement running to 31 December leaves the October, November and December visits in place, because you are still paying for them. If you had already set an earlier end date yourself, that earlier date is kept.
• Confirm renewal, with a new expiry date, carries the end date forward to the new date, but only if the two matched to begin with, meaning you accepted the suggested date. A template that repeats forever goes on repeating forever, and an end date you chose yourself stays where you put it.

Ending a contract does not archive the template. It stays where you can find it, and the visits still covered by the contract go ahead as scheduled. Once the end date has passed, its schedule line reads "Ended" with the date.

When an instance generates

Each generated task lands in the assignee's task list. They work through the checklist, attach photos, record any expenses incurred (e.g. a replacement part), and mark Complete. The recurrence rolls forward automatically.

For a visit, what the Complete step asks for (which documents to attach and which fields to fill) is driven by your recurring-task workflow (Settings → Configuration → Workflows → Recurring task), not a fixed form: a workspace admin can add attachment slots or input fields to the operator step and they appear when completing. Whatever's captured shows in the task's Workflow documents, and any later review/approval steps (PM, GM) are approved or returned the same way as maintenance.

The Free plan caps recurring task templates at 10. Paid plans are unlimited.

Maintenance vs recurring: when to use which

Roles and permissions

There is no role called "Maintenance". Four boxes in the role editor decide who does what, and they are separate so a technician does not also get a manager's reach:

Whoever holds the current step of the maintenance workflow can always act on that job, with or without these boxes: being handed a step is itself the authority to finish it.

Recurring templates are separate again, under Manage recurring tasks.

You can change all of this. See Roles and permissions and the Permissions reference.

Requests from residents

Residents get a login of their own to report a problem in their home, instead of phoning the office. Nothing they send becomes work until one of your people has looked at it and accepted it.

The resident portal is off in every workspace, new or existing, until a workspace admin turns it on under Settings → Configuration → Modules, under Resident portal. It is not available on the Free or Solo plans, and you can turn it on during the free trial.

To start:

1. Turn on the resident portal under Settings → Configuration → Modules.
2. Open a live contract and press Create access link in its Residents section.
3. Send the link to the tenant. They sign in with the mobile number on the lease and report their first problem.
4. Their requests reach you in Maintenance under the Resident requests tab, where you accept or reject them.

Turning the portal off pauses it. While it is off, requests residents have sent that are still waiting for a decision can be neither accepted nor rejected, and residents cannot send a new request or edit one. Requests you already accepted are ordinary maintenance work and carry on as usual. The same happens when your plan stops including the portal, for example when your free trial ends and the account moves to the Free plan, or when you move to Solo. So deal with the requests that are waiting before you switch the portal off or change plan.

Access comes from the lease

You do not add residents. The lease already says who lives there, so anyone named on a live contract can sign in: the tenant, or on a company lease the representative. Nothing to link, nothing to attach, nothing to remember when somebody moves.

A tenant signs themselves in, with no invitation and no waiting. They open the link you send them, reach a page called Sign in to your home, enter the mobile number on their lease and then the code we text them, and land straight on My requests. If they changed their number after signing, they press My number has changed and enter their current number together with the ID or Iqama number printed on the lease. To come back later, they open the same link or sign in with their mobile number on the sign-in page.

Somebody who is not on the lease. A spouse, an adult child, a building supervisor the tenant hired, or the facilities manager of a company tenant. Add them from the same section with Add someone, and write why: that note shows on the row so it still makes sense a year later.

A party you do not want in. Use Remove access on their row. The lease is unchanged; only their access to the portal is.

Stopping someone, and letting them back

Two controls, and they do different things.

Pause new requests is for a resident who is reporting too much, or who needs to speak to you first. They stop being able to open anything new and keep reading everything they already sent, including work still in progress. You are asked for a reason, and the resident is shown it word for word, so write it for them. Lift it whenever you like.

Where you do it depends on who you are. If you approve resident requests, pause and unpause are on the resident's row in the Residents section of the contract, which is the screen you already work from. Workspace admins can also do it from Settings → Users Directory → Residents, which is admin-only.

Revoke sign-in is for access that should never have existed: a wrong match, or somebody who is not who they said. It unlinks that sign-in from the lease, so they can no longer report anything through it and cannot sign themselves back in with the same number. They keep reading what they already sent. This one lives in Settings → Users Directory → Residents, on that person's row, and only a workspace admin can do it.

If you revoked because the wrong person claimed the lease, you do not need to restore anything: send the access link again and let the right person sign in. Their sign-in replaces the revoked one and the row goes back to normal.

Telling residents apart at a glance

Settings → Users Directory → Residents lists everyone. A row shows a badge when something is stopping that person:

• Paused: you paused them. Hover the badge to read the reason you gave.
• Past tenant: no live lease names them any more. They can read what they sent but cannot open anything new.
• Sign-in revoked: their sign-in was revoked and nobody else has signed in as them since.
• Not signed in yet: no sign-in is attached to them. This is the one to chase with an access link.

A resident with no badge can use the portal without restriction. To show one group, use the filter above the list, for example Never signed in, which is the quickest way to see who you have not reached yet.

When a lease ends

Access follows the lease and ends when it does. There is nothing to switch off.

• While the lease is live, and while it has expired but not been closed, they can report problems as normal. Somebody still living there with a broken air conditioner should not be locked out on a technicality.
• When you renew, access carries over by itself. The new contract names the same people, so nobody has to do anything.
• When you close the lease, they can no longer open a new request. They keep reading the ones they already sent, and the page tells them why the button has gone.

What a resident sees

They see one page: the requests they sent, and a button to send another. They never see a request somebody else sent, including a flatmate, and never one your staff opened.

Sending a request. The resident presses Report a problem, writes what the problem is and describes what happened, and says where it is: inside their home, or In the building, not inside my home for a shared area. They can add photos, then press Send.

On each of their own requests they see the stage it has reached: sent, approved, work under way, done. Everything else is off until you turn it on. In Settings → Configuration → Resident portal there are four switches:

• files attached at each step of the work
• values recorded at each step, such as notes or readings
• the name of the person doing the work
• what the work cost

All four start off, so a resident sees progress and nothing more until you decide otherwise.

Changing a request. A resident can edit what they wrote while it is waiting for your decision. Once you accept it, it is fixed, so it stays as you read it when you decided. If you reject it, they see your reason and a Revise and resubmit button: they correct the same request and send it back to you under the same number, and you are notified to look at it again.

What the resident is told

Three things, all about their own request:

• you accepted it,
• you refused it, with the reason you wrote,
• the work is finished.

They are not told about the steps in between. Who is reviewing it, what it cost and who did the work are yours, and the four switches above are what decide whether any of that is ever shown.

A request that changed since they last looked carries a New marker on their page. They tap it to clear it. There is no email or text message behind this yet, so they see it when they next open the portal.

Deciding, and stopping somebody

A resident's request appears in Maintenance under the Resident requests tab, with a count on it. Accept and Reject are both on the card. Accepting turns it into an ordinary maintenance request and starts your normal maintenance workflow; rejecting asks for a reason, which the resident reads. Whoever has to decide gets a notification. On the web it opens this tab for anyone who holds Approve resident requests on that property. Somebody handed the step without that permission gets the task page instead and accepts the request there; rejecting stays with the permission holders.

Who can decide. The Approve resident requests permission, held by Property Manager and General Manager by default. It is separate from reviewing maintenance work, because deciding that a job should happen is not the same as signing off a job that has been done. It is deliberately not given to Operator: the person who does the work does not decide whether it happens.

The approval chain. Every request goes through one step, Review Resident Request, assigned to the Property Manager. Accepting lets you add a note for the resident; rejecting requires a reason. You can change this chain, for example to set a deadline after which it escalates to another role, under Settings → Configuration → Workflows → Resident Request Approval.

Somebody who will not stop. Pause their new requests from the Residents section of the contract or from Settings → Users Directory → Residents, as described in Stopping someone, and letting them back. A pause stays in force through a renewal. If somebody has access they should never have had, a workspace admin can Revoke sign-in from the same list, which also stops that number signing in again.

Residents never use a paid user seat, and they can never be given a role or staff access. Somebody who is going to work for you is invited as staff instead.

Related

• Workflows and approvals
• Money
• Roles and permissions