Sign in

Service · Explanation

How Jobs And Activities Fit Together

Published documentation for BMS Cloud.

How jobs and activities fit together

A service job in BMS is two things at once, and most confusion about the Service screens comes from treating it as one.

The job is the customer's problem. It is raised once, against one asset, with one description, and it lasts until the problem is resolved. The activity is an attempt at that problem — a visit. A job has one activity per attempt.

Why the split exists

A single visit rarely resolves a fault. The engineer attends, finds the part is wrong, and returns a week later. Both trips are real: both consumed a person's day, both may have consumed parts, and both may be chargeable. But the customer reported one problem, and will ask about it by one reference.

Recording that as one job with two activities keeps both facts. The customer's question — "what is happening with my jammed machine?" — has one answer. The business's question — "what did that fault cost us?" — sums the activities.

An alternative would have been two jobs linked together. BMS does support that shape for a genuinely separate return visit, through a callback chain that points a new job back at the one it follows. But the ordinary case of "we went back" is an activity, not a new job, because the problem never changed.

What follows from it

Almost everything real hangs off the activity. The assignee, the parts, the asset, the chargeability, the invoice lines. The job row itself carries the customer, the description and the totals rolled up from its activities. A job with no activities has nothing on it at all.

The two carry separate statuses, and they routinely disagree. A job is Open while its current activity is Raised; both are true, and they answer different questions. The Jobs list shows the activity, because the desk works visits. The job screen shows the job, because that is what the customer asked about.

Cancelling gets harder as work accumulates. Once any activity is closed, the job cannot be cancelled — there is a record of work done, and possibly parts consumed. It has to be resolved through the normal path instead. This is deliberate: cancellation would quietly discard something that really happened.

Where it shows up elsewhere

The mobile app engineers use is a view over activities, not jobs — an engineer is given a visit. Supply and parts flow into activity lines from stock. And the service agent, not the engineer, is the unit of responsibility: the agent is who the work belongs to, the engineer is who attends, and an engineer can attend for more than one agent.

Related