Skip to main content

Solving Assignments — best practices

How to write resolutions others can rely on, record work you couldn't finish, and add a review step with Assignment Definitions.

Written by Logan Bowlby

Overview

Resolving an Assignment turns work in progress into a record that the next shift, your manager and an auditor will read. This article covers how to write a useful resolution, what to do when you can't fully fix something, and how to add a review step with Assignment Definitions.

At a glance

Who can do this

The Assignment's assignees (directly or through a User Group), its creator, a Role with Assignments › Modify, or Super Users. A definition's Who can resolve can narrow who resolves.

Where

Assignments in the Backend, or the Assignment's Solution in the mobile app

Works on

Backend (web), Mobile app

Availability

All organizations. Custom Final states and review steps need Assignment Definitions — ask your CSM to enable Assignment Definition functionality.

💡 Why this matters: A resolution is read long after the work is done, by people who weren't there. Write it for them, not for yourself in the moment.


What a resolution contains

When you resolve an Assignment you record a description of what was done and, optionally, attachments. Mobaro stamps it with who resolved it and when, and adds it to the activity feed.

With an Assignment Definition you can also:

  • Choose between several Final states, such as Fixed and Not fixed.

  • Require a description for a Final state by ticking Require documentation.

  • Limit who can move the Assignment to a Final state with Who can resolve.


Write a resolution others can use

  • Describe what you did. "Replaced sensor unit on lap bar 4" is useful. "Fixed the issue" isn't — the reader six months from now doesn't have your context.

  • Record side-findings separately. If you notice a different problem, create a new Assignment or a Note for it rather than burying it in the resolution.

  • Attach evidence when it adds value. A photo of the replaced part or the finished area often says more than a paragraph.

  • Keep one scope per Assignment. If the work covered two unrelated fixes, create a second Assignment and resolve each separately.


When you can't fully fix it

Mobaro has no "partially resolved" or "could not resolve" flag. Use one of these instead:

  • Leave the Assignment open, comment on the blocker (a part on order, a manufacturer visit), and reassign it or move the deadline.

  • With an Assignment Definition, use a Step state such as Waiting for parts, or a Final state such as Not fixed if the work is closing without a fix. The State column then shows which outcome applies.

🛑 Critical: Don't resolve an Assignment while the problem remains. Finishing an Assignment that is High priority, or at a Critical for operation priority, can turn its Location green (ready for operation) on the Location Overview, unless something else still holds it red. Only finish it when the work is actually done.


Add a review step before closing

Assignments have no built-in approval or sign-off. With an Assignment Definition you can build one:

1. Add a review state

In the definition's States, add a Step state such as Awaiting review. Technicians move the Assignment there when the work is done — in the app, with the State field.

2. Limit who can resolve

In Who can resolve, add your supervisors' User Group. Only its members can then move the Assignment to a Final state. Super Users can also do it in the Backend.

3. Require documentation

Tick Require documentation on the Final states so the reviewer must write a resolution. See Using Assignment Definitions.


When the issue comes back

Reopen the original Assignment in the Backend rather than creating a duplicate: move it out of Finished and give a reason. The original resolution stays in the activity feed.


Patterns to avoid

  • An empty resolution. An Assignment closed without a description tells a reviewer nothing about what was done.

  • "Resolved, but…" If the description has caveats, the work isn't resolved. Keep it open or use a state that says so.

  • Buried side-findings. A problem mentioned only inside another Assignment's resolution rarely gets acted on.

  • No evidence on safety-critical work. For regulated or safety work, the photo or attachment is part of the record.


Best practices

  • For most operational Assignments, one clear photo and one descriptive sentence is the right level of detail.

  • Agree as a team what each Final state means, so filters and reports stay consistent.

  • Use comments to log progress on long jobs, so the resolution only needs to cover the outcome.


Frequently asked questions

Can assignments be validated or approved before they're closed?

Not out of the box — Assignments have no approval step. With Assignment Definitions, add a Step state such as Awaiting review and limit Who can resolve to your supervisors' User Group, so only they can close it. See Using Assignment Definitions.

How do I record a partial repair?

Keep the Assignment open and comment on what's done and what's left. With an Assignment Definition, use a Step state such as Partly fixed, or a Final state such as Not fixed if it closes without a full fix. There's no "partially resolved" flag.

Can we make the description required when an assignment is resolved?

Yes, with Assignment Definitions: tick Require documentation on the Final state. Standard Assignments can be resolved without a description.

Can I edit a resolution after the assignment is closed?

No. Add a comment, or reopen the Assignment and resolve it again. See Resolving, documenting, and reopening Assignments.

Can someone resolve an assignment that isn't assigned to them?

Yes, if they created it, are a Super User, or have a Role with Assignments › Modify. A definition's Who can resolve can limit this. See Understanding assignment statuses.

Did this answer your question?