SCOT — SAPconnect Administration for Outbound Communication

SCOT is the administration screen for SAPconnect, the layer that routes SAPoffice documents out of the system to external recipients through email, fax, X.400, or RFC-based channels. It defines communication nodes: named configurations that pair a channel type with an address area and a destination, usually an RFC destination pointing at an external gateway or an ICM service handling SMTP directly. The structural fact that explains most confusion: SCOT only configures. It does not process the queue and it does not show whether a specific mail went out. Sending is done by a periodic background job that picks up entries from the send request queue, and the result of each attempt is visible only in SOST. Consultants who open SCOT expecting to see failed mails are looking in the wrong transaction.

SCOT is used during initial setup of outbound email or fax, whenever a new SMTP relay, fax gateway, or RFC destination needs to be attached to a node, and whenever the default node needs to change, for example after an infrastructure migration to a new mail relay. It is also reached for during incident triage when business notifications, workflow mails, or output-managed forms are not reaching recipients, as the first check to confirm the node still points at a live destination. It is not used for day-to-day monitoring of individual sends; that role belongs to SOST. There is no Fiori app replacing SCOT; it remains a backend configuration transaction used exclusively by Basis or technical administrators.

Start in SOST, not in a table browse: filter by date range and status to isolate red or yellow send requests, open one, and read the error text, which usually names the node and the transport failure. Cross-check SM37 for the periodic SAPconnect job to confirm it actually ran in that window rather than being stopped or overlapping with a prior run. If the error text points at connectivity rather than content, run the node test again from SCOT and check the underlying RFC destination with a connection test, or the ICM service status, for the actual transport error rather than guessing from the SOST text alone.

The SAPconnect architecture is unchanged on S/4HANA; SCOT and SOST remain the configuration and monitoring pair with no dedicated Fiori replacement. What has shifted is upstream: more outbound documents now originate from newer output management and form frameworks rather than classic SAPscript, but they still funnel through the same nodes and the same queue once they reach SAPconnect. Fax and X.400 nodes are largely legacy at this point; SMTP over an ICM service is the default channel in current implementations.

SCOT itself is Basis territory: node configuration, RFC destination health, and ICM service status. Functional teams own why a particular business document was supposed to trigger a mail in the first place, which is an output determination question, not a SCOT question. A clean handover from functional to Basis includes the SOST status and error text, the node name involved, the business document number, and the timestamp of the failed attempt.

SOST is the natural next stop for anyone who lands on SCOT while chasing a specific failed mail, since it shows the actual send attempts and error text that SCOT configuration only sets the stage for. SM59 is worth reviewing whenever a node's connection test fails, since most nodes route through an RFC destination that can be tested independently. SMICM is relevant when the node relies on SMTP through the ICM rather than an RFC-based gateway. SLG1 gives the detailed application log behind terse SOST error text when the failure is intermittent or transport-related rather than an obvious configuration mistake.