Most descriptions of a fax service are feature lists. This one is a description of how the parts fit together, because that is what determines where your responsibility ends and the service's begins, and it is the thing you need in front of you when you are deciding what to integrate and what to leave alone.
LABUSA eFaaS accepts documents on four paths. They differ in what starts the transmission and in what the originating system has to know, and they converge on the same processing and delivery behavior.
The four paths in
An authorized user composes a message, represents the destination number in the addressing convention defined for the service, attaches the document, and sends. The service accepts the submission, converts the attachment into a fax transmission, attempts delivery, and returns a status to the user or to the workflow behind them. Nothing is installed on the desk and no fax hardware sits beside it.
The appeal is that the interface is one people already use. The cost is that everything email already carries applies here too: who can send from that mailbox, what the mail platform does with the attachment on its way through, and what remains in a sent folder afterwards.
Inbound to a number
A fax arrives at a number assigned to the organization. The service takes delivery, processes the document, and routes it to an authorized mailbox or into a workflow. From the sender's point of view nothing has changed: they dialed a fax number and it answered. From yours, there is no machine to keep loaded and no line to keep alive.
Application, through the API
A business application submits the document and the destination directly, over an authenticated call, and receives a transmission status back that it can log, display or act on. This is the path for anything that already knows what it wants to send and to whom: a records system, a case management tool, a line of business application.
Device, through a connector
A multifunction copier or scanner captures a document and an application or connector submits it to the API on the device's behalf. Whether that connector is device software, print management, a document management system or something written for the purpose depends entirely on the fleet. The point of the pattern is that the scanned document enters an application workflow and is submitted programmatically from there.
What the service does in the middle
All four paths meet at the same place. The submission is authenticated and validated. The document is converted into a form the fax network will carry. Delivery is attempted, with the retry behavior that fax has always needed because the far end is frequently busy, slow or a machine having a bad day. The outcome is recorded and returned.
That record is worth dwelling on, because it is the part that a fax machine never gave you. A transmission has an identity, an origin, a destination, a time, an outcome and a reason if it failed. That is what makes the workflow auditable rather than merely functional.
Where the boundaries sit
An architecture diagram is most useful when it shows where things stop. Three boundaries matter.
- Before the service. Identity, device security, mail platform configuration and whoever decided the destination number is correct. The service accepts what it is handed.
- Inside the service. Authentication of the submission, conversion, transmission, retry, and the record of what happened.
- After delivery. The far end is a fax endpoint you do not control. Delivery to it is a report about a transmission, not a report about what the recipient then did.
Most disappointment with fax services comes from expecting the middle boundary to cover the outer two. It does not, and no service can make it.
What this means for integration
Choose the path by what the originating system already knows. If a person is deciding what to send, email is the shortest route and needs no development. If an application already holds the document and the destination, the API removes the person from the loop entirely and gives the calling system something to log. If the document starts life on glass, the device path is really the API path with a connector in front of it.
What LABUSA provides on two of these paths is described separately, in LABUSA email-to-fax and LABUSA API-to-fax.
Mixing them is normal. A district might send from email in the front office and from an application in student records, and receive everything to one set of numbers. The paths are not exclusive and they share the same processing and the same record.
What the architecture deliberately does not do
It does not change the far end. The destination is still a fax endpoint, reached over the fax network, and it still behaves the way fax endpoints have always behaved. A service can retry intelligently and report precisely, but it cannot make a busy machine answer or make a wrongly dialed number wrong in a way that anyone notices at the time.
It does not confer a compliance status on the organizations using it. Where records carry obligations under health, education, financial or public records rules, those obligations sit with the organization that holds the records. What the architecture provides is the material an organization needs to meet them: controlled submission, a record of what happened, and configurable handling of what is retained. What it cannot provide is a judgment about whether your own workflows are adequate.
And it does not replace the decision about which documents should travel by fax at all. Some do, because a partner requires it or a process has been built around it. Others travel by fax only because they always have. The architecture is worth applying to the first group.
Where to go next
If fax mechanics themselves are the unfamiliar part, start with what electronic fax is and the broader guide to electronic fax. For the application path in detail, see electronic fax APIs explained. For what the service does rather than how it is shaped, see the feature overview. To work through which paths fit your environment, tell us what you are working with.
Sources
- ITU-T Recommendation T.38. Procedures for real-time Group 3 facsimile communication over IP networks, in force at edition 11/15. The standard the fax leg of this architecture ultimately conforms to.
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. The Audit and Accountability control family describes what a transmission record is for.