Well, for starters, let's take aside discussions about whether it's a good or a bad practice saving different states on a single record, because that would be off topic.
That being said, consider this example:
A user enters a e-commerce website and buys 1 item. A can of beer, for example.
This can of beer has to be paid, packaged and delivered. There are 3 different workflows involved.
Of course your could say that this consider a state machine, with the order containing 4 states:
Waiting Payment -> Paid (Waiting Packaging) -> Packed (Waiting Deliverance) -> Delivered
But each state has an inner workflow. Waiting Payment may involve actually sending the payment request to a credit card company, waiting return, rejected payments from the CC company, changing methods, etc...
Waiting Packaging means you may have to request transfers of that item from one storage location to another, approvals from different personnel, and on until someone (or something) puts a box around the can of beer, prints a label with the customer name and address and actually makes the box available for the logistics guys deliver the package.
Packed means someone has to actually sign off that the package was picked up at the storage location, place on a truck or plane, get a tracking number, etc...
Get the idea ?
Everything can be tracked within a single record, specially one with hundreds of fields. It doesn't mean it should be like this, but your business reality will tell what would be the optimal solution.
So, wrapping up:
"Does that mean my 1 order record contains many state machines?"
In the example above, yes. One state for each workflow.
"If so, then what, and does it lose it's power?"
I don't understand what do you mean by "lose it's power", but certainly storing different workflows under a single record may make your life harder as a developer, due to mixing different domains without proper boundary definition among them.
