ServiceNow IntegrationHub resolves an alias to connection information and credentials when an integration runs. A flow can use several connections to one provider, and its preset connection can be overridden at the flow, subflow or action level. For a buyer, that makes the security question more precise than “Is the ServiceNow instance secure?” The question is which identity and endpoint a specific action used for a specific record, and whether that use matched the approved business rule.
Quick answer. Commission an IntegrationHub connection alias assessment when a customer-owned flow can send or retrieve sensitive records through a spoke or custom REST action. Scope the aliases and child aliases, selected connection and credential, every applicable flow, subflow and action override, the resolved outbound destination, the external API's permissions, and any MID Server path. Stingrai's web and API penetration testing can examine the customer-controlled application and API decisions with synthetic records; quote external services and infrastructure separately where authorized.
This guide is for a ServiceNow platform owner, integration lead, security architect or procurement team preparing a statement of work before an outbound workflow goes live or changes materially. It addresses the customer configuration and custom application boundary. It does not assume permission to probe ServiceNow's underlying platform, another vendor's tenant or a private network. ServiceNow's current Security Best Practices Guide places customer application penetration testing on sub-production instances under its Customer Penetration Testing Policy. The buyer should obtain the current account-gated policy through Now Support and coordinate the authorized test.
The buyer decision: prove the path the flow actually takes
A standard instance assessment may check authentication, role access and application endpoints. An IntegrationHub review needs to follow a second trust path: a trigger reads a customer record; a flow or subflow calls an action; the action resolves a connection alias; the selected connection supplies destination and credential context; an outbound request reaches an external API, directly or through a MID Server; the response may update a record or become an attachment. Each transition can alter who receives data or what authority acts on it.
The ServiceNow connection documentation explains why the configured alias is only the starting point. An alias enables the integration to obtain connection and credential information at runtime. Supporting multiple connections shows that a flow-level selection can apply to all actions and subflows using an alias, while more specific overrides can change the result. An assessment that lists aliases but never observes a flow execution cannot establish which connection was used.
The buyer should decide which of three scopes it needs. Configuration review records aliases, connection records, roles and intended destinations without executing negative cases. Customer-instance application test executes approved synthetic flows and verifies the selected connection, outbound request construction and local data disposition. End-to-end integration test also verifies the external API's authorization and, when used, the MID host and private network. The last scope requires separate owners, test accounts and written permissions. A provider should not sell the third scope while delivering only the first.
A useful result is a trace for each important business action: trigger and record class, flow version, alias, effective connection, external principal, destination, transport path, external response, local update, and access to the resulting record. If any item cannot be observed, the report should mark it as an evidence gap. This is a more reliable procurement unit than a count of spokes or endpoints.
Understand alias, connection and credential as separate decisions
ServiceNow describes an alias as a reusable name that ties to connection or credential information. A connection identifies an external system or endpoint. A credential provides authentication data. A connection and credential alias can resolve both at runtime, while a credential-only alias resolves authentication information. These distinctions matter because a reviewer may see a safely named alias even though its underlying connection points to an unexpected environment or its external principal can do more than the flow needs.
An alias may have child aliases with their own connection and credential information. ServiceNow also supports multiple active connections for an alias when configured for that feature. A buyer should include both in the inventory. The presence of a parent alias does not prove which child connection or credential is effective in each run. Record the selected alias identifier, its application scope, connection type, associated connection records, active state, and the intended environment for each, without exporting secret values into the assessment notes.
Authorization to create or view these objects is another boundary. The Brazil release documentation states that an admin creates a Connection & Credential alias, while credential_admin and connection_admin have read access to the alias record. A separate flow override procedure lists flow_designer or admin for overriding a connection. These documented roles are useful test-fixture starting points, not a complete description of every custom role, ACL or deployed family. The buyer should supply its actual role assignments and ask the tester to validate who can configure, select, run and inspect a connection in that instance.
Do not equate credential secrecy with safe use. A user may never view a password and still be allowed to run a flow that uses a powerful external identity. Conversely, a platform administrator may be able to configure an alias but should not use a production partner account in a sub-production negative test. Map both who may manage the connection and who may cause the connection to act. Those are different questions for the application owner and external system owner to approve.
Build a quoteable inventory before testing
Start with the business event, not with a list of ServiceNow tables. A flow that exports incidents to a ticketing partner has different consequences from a flow that imports a vendor risk score or updates a financial approval. The owner should provide a simplified data-flow diagram and an inventory that the bidder can use to price the actual decisions. The example below is a worksheet, not a claim about any customer deployment.
Inventory field | What the buyer supplies | Why the tester needs it |
|---|---|---|
Trigger and record class | Event or API that starts the flow, and the synthetic record type | Establishes which user or system can initiate the integration |
Flow, subflow and action | Published version and exact integration steps | Identifies every point that can choose a connection |
Alias and child alias | Names, application scopes and associated connections | Prevents a parent alias from hiding a different effective route |
Intended connection | Development, test or production partner account and endpoint | Gives a positive expectation for each environment |
External principal | Service account or delegated identity, with approved API rights | Shows the authority the outbound action exercises |
Destination | Approved host, API operation and data class | Defines what may leave the instance and where it may go |
MID path | Direct call, named MID Server or cluster, and network owner | Marks a separate infrastructure and private-network boundary |
Response disposition | Record update, attachment, log, retry or error handling | Catches sensitive data that re-enters a different access context |
Evidence owner | Which party can provide ServiceNow and external logs | Avoids a bid that cannot verify the final outcome |
ServiceNow's REST step documentation makes the destination inventory especially important. An action can use a connection alias or define a connection inline, and the base URL shown from an alias can be overridden in the REST step. The buyer should therefore list the action's effective base URL, path and operation as well as the alias. A security test that stops at the Connections dashboard may miss an action-level destination choice.
Ask for one positive and one negative fixture for each material boundary. The positive case proves the approved flow can complete with a synthetic record. The negative case proves an unauthorized role, record, connection, destination or external API permission cannot produce the same result. With only one role and one record, the tester can show connectivity but cannot show separation. Keep fixtures small, invented and reversible, with the owner defining expected outcomes before test execution.
Figure 1: A buyer-designed evidence map. Override precedence and runtime-value behavior follow ServiceNow's multiple-connection documentation; the decisions to test and evidence to retain are editorial recommendations.
Test the connection selected at each layer
The test plan should distinguish the default connection, a flow override, a subflow override and an action override. In ServiceNow's documented precedence, an action-level override applies to that action; a subflow-level override applies within the subflow except where an action has its own override; and a flow-level override applies where neither more specific override is configured. That order is a critical fact for review. The “flow connection” visible to an owner is not necessarily the connection used by every action.
Begin with the normal path. Run the approved flow with a synthetic record and compare the design-time alias, configured override and execution detail. ServiceNow says flow execution details can show a configured alias and a runtime value. Capture the runtime value, not only the diagram shown before the run. If the flow has dynamic inputs, confirm the connection they used; the same multiple-connection documentation says a flow override can affect a dynamic action unless that action has its own override.
Next, examine controlled variations. Use two permitted test connections, such as separate partner sandboxes, and record which one is selected when a flow-level override changes, when a subflow chooses a different connection, and when one overridable action is explicitly set to another connection. Do not infer that every action supports this option: ServiceNow says action-level override is available only when the action has an overridable connection. If an action does not support it, mark that boundary as not applicable rather than inventing a test.
The negative question is who can alter those selections and whether the change is visible in execution evidence. A business user who can trigger a flow should not automatically gain the ability to choose a different partner account. A flow designer who can select an approved connection should not silently send to an unrelated system unless the customer's authorization model allows it. The tester should validate the deployed permissions and audit events under buyer-supplied roles. A screenshot of a disabled control is not enough; compare the actual action outcome and connection used under each role.
Selection case | Expected result to agree before testing | Evidence to retain |
|---|---|---|
No override | Action uses the configured default connection for that alias | Alias, connection record and runtime value |
Flow-level override | Actions using that alias follow the flow selection unless more specific overrides exist | Flow selection and per-action runtime values |
Subflow-level override | Actions within the subflow use its selection unless an action overrides it | Subflow context, action runtime value and external receipt |
Action-level override | Only the eligible action uses its explicitly selected connection | Action configuration and its observed destination |
Unauthorized editor | Role cannot make or persist a connection change beyond approved rights | Role, attempted change, result and audit trail |
Unconfigured promoted connection | Flow fails safely or is held until the new environment is configured | Promotion record, configuration state and test outcome |
The last row matters in release planning. ServiceNow states that when a flow is moved to production, its alias information moves but the underlying connection information does not. The destination has to be configured again. A release gate should verify that a production alias was bound to the intended production connection and credential, rather than assuming the development connection traveled with the flow. The assessment can inspect that gate without running a penetration test against production.
Follow the outbound request beyond the alias
A selected connection is not the end of the security decision. The action chooses an HTTP method, path, inputs and sometimes a base URL override. The external API determines what the chosen principal may read or change. The buyer's test must ask whether the ServiceNow record being processed is authorized for that destination and whether the external principal is limited to the intended operations. These are application and partner policy questions; ServiceNow's connection configuration does not define them for every customer.
For a custom action, ServiceNow's REST step can use an alias or an inline connection. It can also override the base URL associated with an alias. A scope brief should therefore distinguish the connection selected, the destination actually called and the API operation the external principal can perform. A valid alias paired with a broader path or different host can reach a different trust boundary. Testers should not attempt arbitrary hosts. Use only buyer-approved sandbox endpoints and a written allowlist.
A practical positive case is a synthetic record that is permitted for Partner A's test account and one permitted operation. The negative case may be the same record under a role that cannot initiate the export, a record from another business domain, or an operation the external test account is not allowed to perform. Compare the ServiceNow trigger result, action's effective destination, external API response and any resulting ServiceNow update. If the external API owner cannot provide a log or test tenant, label the external authorization result unverified. A successful local flow state alone cannot prove the partner enforced its permissions.
The request body needs its own review. An action might map an entire record when the integration contract requires only a few fields. The tester can use an invented record with distinctive markers in permitted and forbidden fields, then inspect the approved partner sandbox request or receipt. This demonstrates whether the intended data subset leaves the instance without exposing real employee, customer or patient data. The test should also record whether headers, status messages and flow execution details expose data beyond the people who need it.
The response can create a second exposure. ServiceNow's REST step includes a Save As Attachment option, which associates a response with a record. If a flow uses it, the assessment should verify the target record, its access controls, the attachment's lifecycle and whether a different user can retrieve the saved response. A response may be safe at the external API but unsafe when filed under a broadly readable ServiceNow record. If the flow instead parses a response and updates fields, test the resulting record permissions and exception path.
Retries should be part of the business contract. A transient failure may cause a repeated request; the buyer should define whether the external operation is idempotent, whether a retry can create duplicate records, and what approval is required before replay. The REST step has retry-policy controls, including an option to override the alias default. A bidder should state whether the review includes retry configuration and one synthetic failure case. The goal is to confirm the intended behavior, not to flood a partner API or test live rate limits.
Separate direct, MID and private-network boundaries
A flow may send its request directly from the instance or through a Management, Instrumentation, and Discovery (MID) Server. ServiceNow explains that a MID Server can let an outbound REST request reach an endpoint behind a firewall or in a private network. The difference is material to an engagement. The MID host, its operating system, network route and accessible internal endpoints are customer infrastructure, while the ServiceNow instance remains a hosted service. A test of the instance's integration logic does not automatically authorize probing the MID host or its reachable network.
The buyer should identify the chosen MID Server or cluster, its owner, egress controls, proxy and firewall route, and the external or internal endpoint that will receive the synthetic request. If the MID is outside the engagement, the assessor can still inspect the configured route and ask the customer to provide a redacted destination receipt. If the MID is in scope, define exact host, allowed accounts and interfaces separately. The ServiceNow Security Best Practices Guide places MID Server operation, hardening, account management and network restrictions with the customer. That is a reason to name the owner in the SOW, not a reason to perform unapproved host testing.
For mTLS integrations, ServiceNow documents outbound REST and SOAP calls through MID using a MID Protocol Profile. It describes certificate and credential material stored on the instance, in a MID configuration file or in an external vault. The security test should establish which design the customer actually uses and who can change the profile, certificate association and destination. It can verify the external sandbox rejects a client identity that is not approved, provided the external owner authorizes that case. The report should identify the material's location and management owner without copying private keys, passwords or certificate secrets.
Evidence planning differs for MID-routed calls. The REST step documentation notes that request, response and parameter runtime data sent via MID are not logged the same way as ordinary outbound web-services logging; flow execution details provide a view instead. A bidder promising a log-based trace should say which log or execution view will supply each field. The external API's log may be needed to prove the receiving identity and operation. If a redacted MID or proxy log is part of the plan, arrange access before the test window.
A private endpoint may require special care with synthetic traffic. The buyer should arrange an isolated test listener or a dedicated partner sandbox where possible. If a flow normally reaches production infrastructure from a sub-production instance, the owner should either reroute its test connection to a controlled endpoint or explicitly approve a tightly bounded fixture. Never assume that “sub-production ServiceNow” means the downstream destination is also nonproduction. The connection and override inventory must name both sides.
Examine configuration rights, data domains and runtime rights
IntegrationHub configuration spans several rights. The alias owner may create or maintain a connection, a flow designer may select an override, an action designer may build the REST step, and a business user or service account may trigger the flow. The roles named in ServiceNow documentation are an entry point; custom ACLs, delegated development and domain setup can change real access. The tester should use buyer-provided accounts representing the relevant jobs and observe allowed and denied actions under each.
For a managed-service instance, domain separation deserves an explicit case. ServiceNow supports domain separation for credentials and connections, and a connection may be global or assigned to a specific domain. A buyer should identify which domain owns each flow, connection and test record, and decide whether a globally available connection is intended. The assessment should verify a record from Domain B cannot be exported through Domain A's partner account merely because the same alias name or action is visible. The exact expected result depends on the customer's design; there is no universal “all global connections are wrong” rule.
Review the trigger, too. A flow may be correctly configured yet be callable from a portal action, inbound API or record update available to too many users. The test should ask whether each initiating identity may use the external principal for the requested operation. In a quote, this means authenticated roles and representative records are mandatory. A scan from an anonymous browser cannot answer who caused the service account to act on a record.
The evidence must avoid turning a security review into credential collection. Ask for alias identifiers, connection record names, external principal identifiers, role assignments and redacted execution details. Avoid raw token values, passwords, keystore files and full production request bodies. A tester can demonstrate a wrong permission using synthetic records and redacted traces. If a real credential is accidentally exposed during testing, stop and use the customer's incident and rotation procedure rather than embedding it in a report.
Make promotion and change control part of the scope
Promotion from a development flow to a production instance is a configuration boundary, not merely a deployment step. ServiceNow says the alias information transfers but the underlying connection information must be configured again. This can be beneficial because test credentials do not automatically become production credentials, but it also creates a moment where the wrong account or destination could be selected. The release owner should verify the newly configured connection against the approved inventory before enabling the flow broadly.
A useful release artifact is a signed-off table containing alias ID, application scope, selected connection, external principal, destination host, MID selection, owner and a synthetic post-promotion result. The assessment can review this artifact in sub-production or against a noninvasive production configuration export that the customer provides. It should not run negative tests against production merely to prove a release checklist was followed. If the buyer wants live integration verification, name a harmless test record and external sandbox account, obtain the relevant permissions, and distinguish that activity from a penetration test.
Retest triggers should follow the trust path. A new child alias, connection or credential; a change in flow, subflow or action override; a modified base URL; a new external API permission; a new MID route; a change in data mapping or response storage; and a promotion into a new instance can each alter the result. The buyer can use the earlier evidence package as a baseline, then ask for focused retesting of the affected transitions. A report tied only to a spoke name or an instance URL is difficult to reuse when the actual connection selection changes.
An evidence matrix a buyer can attach to the RFP
The matrix below is written as a contracting aid. It sets no claim about a default ServiceNow configuration. The buyer should replace the synthetic names, expected outcomes and authorized systems before asking vendors to price it.
Boundary | Positive fixture | Denied or exception fixture | Proof of outcome |
|---|---|---|---|
Trigger authority | Approved role initiates a synthetic export | Unapproved role tries the same record and action | Initiating identity, flow context and result |
Record and domain selection | Domain A record uses Domain A approved connection | Domain B record attempts the Domain A route | Record context, effective connection and destination receipt |
Alias resolution | Parent or child alias resolves to the approved sandbox connection | Stale or unintended child connection is selected | Alias ID, connection name and runtime value |
Override precedence | Flow, subflow and action selections match the approved policy | More specific override points to an unauthorized partner account | Design-time selections and each affected action's runtime value |
Destination and operation | Approved REST host and operation receive allowed fields | Base URL or operation differs from approved contract | Redacted request metadata and external API log |
External principal | Test account performs allowed operation | Same account attempts a disallowed operation | Partner-side authorization result and account identity |
MID route | Named MID reaches approved test endpoint | Wrong MID or unauthorized private endpoint is selected | MID selection, route owner and receiving endpoint evidence |
Response handling | Allowed response updates the intended record | Response attachment or field lands on a broadly accessible record | Target record, access result and redacted attachment evidence |
Failure and replay | Controlled transient failure receives approved handling | Retry creates duplicate or sends to wrong partner | Retry policy, execution history and final external state |
Promotion | New environment is configured to the approved account | Alias exists but connection is unconfigured or misbound | Release configuration and synthetic verification result |
The vendor should mark each row in scope, buyer-provided evidence or excluded. The first label means the tester can execute and observe it. The second means the customer or partner will supply a log or configuration proof. The third should name the owner and consequence of the gap. This prevents an attractive “end-to-end” description from hiding a test that never reaches the receiving API or MID route.
Rules of engagement for a customer-owned instance
The ServiceNow Security Best Practices Guide says customers may perform application penetration testing on sub-production instances in accordance with the Customer Penetration Testing Policy. The current policy is available through a ServiceNow Support account. The buyer should obtain and follow it, including the applicable request, scheduling, target and reporting instructions. This article does not substitute for those account-specific terms.
Name the instance and release family, target application and exact URLs; give the tester synthetic identities and records; define allowed hours, request volume, safe stop conditions and contacts. Limit the action set to approved flows and partner sandboxes. A flow test can have side effects far outside the instance, so obtain external API owner's permission and agree on cleanup. Where the route uses a MID Server, the customer infrastructure owner should approve any host or network verification separately. ServiceNow permission for customer-instance testing does not grant the tester rights over a third-party API or private endpoint.
The buyer should also decide which evidence can be retained. Flow execution details, partner logs and record snapshots may contain confidential data even when the test uses invented fixtures. Provide the minimum metadata needed to reproduce an issue, redact secret values and unrelated production records, and set a retention period in the engagement paperwork. A report should show the source record, connection decision and destination result with test identifiers, not a dump of credentials or entire operational records.
What to require from the vendor
The deliverable should make each selected trust decision observable. Ask for the final asset inventory, alias and connection map, user and service-account roles, approved fixture policy, tested flow versions, positive and negative results, runtime connection values, outbound destination and external response evidence, MID route evidence where included, validated findings, exclusions, remediation owners and retest results. A finding should identify the exact flow action and connection choice that produced the wrong result. “Integration misconfiguration” is not enough for the platform team to repair it.
A strong bidder will explain who can execute the tests safely, who will read the ServiceNow execution details, whether it needs access to the external sandbox, and how it will verify the final disposition of data. It will distinguish a configuration review from a runtime application test and an external API assessment. It will also state how it handles a flow that cannot be safely triggered in sub-production because its destination still points to production. The responsible answer may be to create an approved sandbox connection and test there before the release.
Ask for a retest on agreed fixes. A correction to a flow override or REST base URL should be verified against the same synthetic fixture and both the selected connection and receiving endpoint. A correction to external permissions needs evidence from the external system owner. A correction to MID egress needs the customer network owner. Separate owners can work in parallel, but the final report should connect their evidence to one business transaction.
Copy-ready scope language
Assess the buyer's named IntegrationHub workflows on its authorized sub-production ServiceNow instance. Inventory each flow, subflow, integration action, connection and credential alias, child alias, configured connection, external principal, REST destination and MID route in the attached asset schedule. Using buyer-supplied synthetic records and approved sandbox accounts, verify which connection each action uses at runtime, including applicable flow, subflow and action overrides; who may configure or trigger that use; what data and operation reach the approved external API; and how the response is stored or displayed. Include the specified positive and denied cases, one controlled retry case where safe, and a promotion configuration check. Deliver a redacted evidence package showing runtime connection values, receiving-system results where access is authorized, findings, exclusions, remediation owners and retest outcomes. Test third-party APIs, MID hosts and private-network endpoints only when each owner has authorized and named them in this scope.
That clause still needs the buyer's asset schedule and rules of engagement. Add the current ServiceNow customer testing policy requirements from Now Support, the exact nonproduction instance, allowed endpoints and external test tenant, and the flow versions. Tell the vendor which parties will provide partner-side evidence and whether the quote includes a MID configuration review, host assessment or neither. A narrow scope can be valid when the customer controls only the ServiceNow side, but the report must not imply it proved the external authorization path.
How Stingrai fits this assessment
Stingrai is a CREST-accredited penetration testing firm that tests web applications and associated APIs for authorization, authentication and business-logic flaws. For an IntegrationHub engagement, the buyer can provide the approved ServiceNow sub-production instance, synthetic records and roles, relevant flow configuration, and authorized partner sandbox. Stingrai can scope an authenticated assessment around the transitions the buyer owns and deliver validated findings with evidence and remediation guidance.
The fixed-price web application packages cover one web application and associated APIs. An IntegrationHub workflow can include a ServiceNow instance, external API, MID host and private-network path, so the buyer should request a custom quote for the actual authorized boundary. The quote should say which components are tested directly, which are reviewed through buyer evidence and which are excluded. That prevents a single-application package from being mistaken for a multi-owner integration assessment.
FAQ
What should a ServiceNow IntegrationHub connection alias security assessment test?
It should verify the alias and child-alias inventory, the connection and credential used by each in-scope action at runtime, the effect of flow, subflow and action overrides, the outbound destination and API permission, any MID route, and the response's final access context. Use synthetic records and separate approved and denied fixtures. A configuration screenshot alone does not prove which connection a flow used.
Is an alias configuration review enough to prove a flow is safe?
No. ServiceNow resolves an alias to connection and credential information at runtime, and supported overrides can change the connection selected for a flow, subflow or action. The assessment should compare intended configuration with flow execution details and the destination's receipt for a synthetic transaction.
Which override takes precedence in ServiceNow IntegrationHub?
ServiceNow documents that an action-level override applies to the action, a subflow-level override applies within the subflow where no action override exists, and a flow-level override applies where neither more specific override exists. Action-level override is available only for an action with an overridable connection. The tester should verify the deployed flow's runtime value rather than infer it from the top-level diagram.
Can a ServiceNow customer penetration test its IntegrationHub flow?
ServiceNow's public Security Best Practices Guide says customers may perform application penetration testing on their sub-production instances under the Customer Penetration Testing Policy. The buyer must obtain the current policy through Now Support and coordinate the authorized scope. External APIs, MID hosts and private-network endpoints require their own owners' written authorization.
Does a MID Server change the IntegrationHub test scope?
Yes. A MID Server can route an outbound request to a private endpoint, adding customer-operated host and network boundaries. The buyer should specify the MID selection and route, external owner, allowed test endpoint and evidence source. ServiceNow notes that MID-routed REST request and response logging differs from ordinary outbound web-services logging, so the team should plan to use flow execution details and approved receiving-side evidence.
What happens to connection information when a flow is promoted to production?
ServiceNow says the alias information transfers with a promoted flow, but the underlying connection information does not. The new environment needs its connections configured. The release owner should verify the effective connection, credential, destination and MID path before enabling the flow, then retain a synthetic verification result.
Can one fixed-price web application test cover the external API and MID host?
Only if the named, authorized assets fit the package's stated scope. Stingrai's fixed-price web packages cover one web application and associated APIs. A ServiceNow instance plus a third-party API, MID host or private-network path needs explicit asset and owner boundaries in a scope-based quote.
Related reading
ServiceNow customer-instance penetration test scope for the broader instance authorization and asset boundary.
Third-party API integration penetration testing for source-to-destination authorization and evidence design.
Mutual TLS API penetration testing scope for certificate identity and API authorization when the outbound route uses mTLS.
API penetration testing scope and methodology for the receiving API boundary.
Sources
ServiceNow, Managing connections in Integration Hub, Brazil release, updated September 10, 2026.
ServiceNow, Create a Connection & Credential alias, Brazil release, updated October 19, 2026.
ServiceNow, Supporting multiple connections, Brazil release, updated September 10, 2026.
ServiceNow, Override a connection in a flow, Brazil release, updated September 10, 2026.
ServiceNow, REST step, Brazil release, updated September 10, 2026.
ServiceNow, Security Best Practices Guide, October 26, 2026.
ServiceNow, Sending outbound REST messages through a MID Server, Brazil release, updated September 10, 2026.
ServiceNow, Using the mTLS protocol with a MID Server, Brazil release, updated September 10, 2026.
ServiceNow, Domain separation and Credentials and Connections, Brazil release, updated September 10, 2026.
Talk to Stingrai
Share your flow inventory, allowed test instance and external-system permissions with Stingrai's quote team. You can also book a free discovery call to settle the connection, API and MID boundaries before the assessment is priced.
