Here you see an overall map of how the various modules in the system are interconnected:

• Report a case via the rental module
  • How to send orders to operations from the rental module
• Report a case via MittBygg (registration solution)
  • MyBuild on the web
  • MyBuild on app
• Report a case via the cleaning module
  • Report deviations from cleaning to operation
• Report a case via the LAFT app (Construction, not illustrated in the image above)
  • How to use the LAFT app for Construction Operations

Cases reported as described above will be placed in the inbox in the DV module. All unprocessed cases, i.e. cases that are missing a deadline and/or are being processed, will be placed in the inbox.

See also guides:

• The inbox in the DV module
• Process work order/routine

Administrators, managers or other roles with access to the inbox can then process the cases further; set a deadline, add more to the task text, attach attachments, assign a performer(s), etc.:

🔗 1. Common database and data model

All modules (for example, maintenance plan, deviation management, documentation, key register, etc.) are connected to a common database . This means:

• When one module updates information (e.g. a deviation is logged), this automatically becomes visible in relevant parts of the system (e.g. maintenance plans, history).
• No duplication of data – the same object is used across modules.

🔄 2. Two-way integration

The modules are usually bidirectionally integrated , which means that:

• Changes in one module affect others.
  • For example, if you update information about a building in the administration pages, this will be reflected in the operations and maintenance module.
• The system updates information in real time across.

🧩 3. Roles and access control

User access is often module-specific , but interaction is still fluid:

• A manager and executor have access to create deviations.
• A technician (supplier) is only allowed to see and process the deviations that have been assigned to him.
• A manager (administrator) can see an overview and history across modules.

📡 4. Cross-platform notifications and tasks

When something happens in one module, alerts or tasks can be generated in another:

• Deviations (orders) from the rental module can trigger new tasks in the DV module.
• Documentation (e.g. drawings) can be available in both projects, maintenance and the property overview.

📱 5. Mobile and desktop in interaction

The interaction takes place on both PC and mobile:

• The app allows users in the field to report discrepancies, take photos, and complete tasks.
• Everything is synchronized with the web solution so that colleagues in the office see updates immediately.

📊 6. Reports and dashboards

Data from all modules can be aggregated to:

• Dashboard (status overviews across buildings or properties)
• Reports (e.g. maintenance per building, deviations per person responsible)

Typical flow – an example:

• A technician reports a discrepancy in the mobile app.
• The deviation is automatically linked to the property, the subject area and possibly a maintenance task.
• The operations manager receives notification and appoints someone responsible.
• When the discrepancy is closed, it is archived as history and can be extracted in reports.