What we built
Email, Telegram and MAX requests pass through shared logic. The system checks the request, finds the object and equipment in M4, follows staff approval and prepares instructions with the required access details. Registering a number on a GSM relay uses a separate technical SMS workflow.
Linking the request to the correct object
Requests may arrive as free text or include a document. The system extracts and checks the details, then links the request to the object and equipment in the operational system.
Access issuance follows staff decisions and workflow rules. Missing or inconsistent information leaves the task with a staff member.
Approval and delivery are separate steps
Request → M4 object
Match the object and check the applicant's document.
Manager approval
Access requires confirmation. General instructions contain no personal data.
Email → delivery handling
Handle immediate SMTP failures and late bounces separately.
SMS fallback through TextBee
If both channels fail, keep the task with a staff member.
Access credentials are separate from general instructions. No real addresses, phone numbers or passwords are shown.
Instructions and access details
Common application setup steps live in web instructions. Credentials and other request-specific details form a separate block, so shared instructions do not disclose individual access information.
The system chooses the instruction for the equipment and prepares the response. Delivery results stay attached to the original task.
Email / Telegram / MAX → request validation
→ M4 object and equipment
→ staff decision
→ general instructions + request-specific details
→ delivery → status or staff taskWhen email fails
Immediate SMTP failures and later bounce notifications have separate recovery paths. Fallback SMS uses the number from the same request and reads access details again from the operational system.
If fallback fails too, the task returns to staff. Gateway acceptance and confirmed delivery are distinct; an HTTP success does not prove the customer received the message.
Commands for GSM relays
Registering a phone number for gate access follows a separate route. An Android phone with a SIM and TextBee receives the technical SMS command, while a queue tracks its state.
Retries are bounded. Pending or already sent messages do not create a new command. Late confirmations are reconciled against history to prevent repeated execution of the same request.
What needed correction
A poller and queue once created a resend loop. We added retry limits and a manual escalation. Another failure treated a sleeping phone's slow confirmation as a definitive delivery failure.
A phone heartbeat also failed to prove that the modem could send. Gateway checks were extended to account for sending errors and the absence of successful deliveries.
The service team's result
A request retains its object, equipment, staff decision and sending result. The same information no longer needs to be copied between channels and assembled into instructions for each application.
Unfinished actions and delivery failures remain visible. Access authorization, disputed documents and exceptions stay in the staff workflow.