A Heavy-Equipment Dealer Turns a Mining Truck's First Connection Into Its Own Files.com Account

A global heavy-equipment dealer sells, rents, and services mining and construction equipment across three regions.

Part of that service is condition monitoring. Connected trucks across the three regions upload sensor data over FTP into the dealer's Files.com site: fuel consumption, failure codes, warning codes. The dealer processes that data and turns it into the maintenance and repair decisions it delivers to its mining customers.

The machines sending that data do not belong to the dealer, and they do not sit on the dealer's premises. They belong to customers, they work at mine sites around the world, and they are configured by whichever technician happens to have the machine in the bay. A new truck can come online and attempt to connect before anyone at the dealer's head office knows it exists. Every one of those machines needs credentials of its own, and getting them there is the hard part.

Every Truck Needed an Account of Its Own

The dealer wanted every truck on its own Files.com account, so that each machine's data, its access, and any login problem it ever has stay scoped to that one machine. Hundreds of trucks across three regions meant hundreds of accounts, each one created for a machine the dealer might not know about yet.

Per-truck accounts were the obvious design. Getting there was the problem.

A Logistics Problem, Not a Technical One

The conventional way to provision an account is that someone requests it, IT creates it, and credentials come back. That sequence fails at a mine site.

The logistics look like this. Credentials get programmed into a truck by hand, by a technician the dealer often cannot identify in advance, during the short window while the machine is out of service. A haul truck is a high-value asset that needs to return to work quickly. The technician may have no access to the dealer's internal systems, and no time to wait on a ticket even if they did. Every extra step in the chain is another point where the onboarding fails and the truck leaves the bay silent.

So the fix had to work backwards from the field. The right credentials had to be knowable before anyone asked for them. The account had to create itself, with no request, no approval, and no human in the loop. And it had to verify that a machine announcing itself was a real machine in the dealer's equipment records. The dealer built that provisioning layer against Files.com, using the platform's FTP action logs and API as the trigger.

Per-Machine Credentials, and an Account That Creates Itself

The dealer inverted the flow. Instead of creating an account and then distributing credentials, they tied the credentials to each machine and let the account follow.

Every machine gets credentials of its own, set by a convention in the field documentation technicians already use. A technician programs those credentials into the truck and closes the panel. The truck attempts to connect to Files.com and fails. That failure is the point.

The dealer built a service to watch the Files.com FTP action logs through the API. When a failed login matched the per-machine convention, the service identified the machine and validated it against the dealer's equipment database. If everything lined up, the service created the truck's account through the same Files.com API. On its next attempt, the truck connected and data started flowing. Failure-then-success was the normal onboarding path, by design.

The whole loop now closes within minutes of the technician's work. Nobody requests anything, and nobody approves anything. The truck announces itself, Files.com records the attempt, and the dealer's service does the rest.

Provisioned Before the Truck Leaves the Bay

With the provisioning service in production, the dealer replaced an onboarding path built on service-desk requests with one the field triggers implicitly.

• A truck has its own working account within minutes of a technician programming it, inside the same service window the credential work already occupies. No return visit, no waiting on a ticket, no extra hour in the bay.
• Each truck's account is its own boundary. A login problem on one machine stays with that machine, and every other truck keeps uploading.
• A machine head office has never heard of can onboard itself. New equipment joins at the customer's pace, and the dealer finds out when the data arrives, which is exactly how they designed it.
• The next truck adds no new administrative step. The credential convention, the logs, and the API do the same work for each machine, which is what makes a per-truck account model workable across three regions at all.

What Changed at the Mine Site

Today, nothing about the technician's job has changed. They program credentials into a machine in a bay, the same as they always did. Everything behind that act has changed. An onboarding process that would otherwise have meant tickets and waiting now requires nothing else of anyone. Files.com records the truck's first knock at the door, the dealer's service confirms the machine is real, and by the time the truck is back to hauling, it has an identity of its own.

The lesson travels beyond mining. When you cannot control who configures your devices, or when, or where, and you may not know a device exists until it speaks, the device's own first login can be the provisioning request. Per-machine credentials and a log-driven check against a system of record turn account creation into something the field does implicitly, and the Files.com logs and API are what let the dealer run that as a production pattern instead of a wish.