Azure Bridge Customer FAQ

This FAQ is written for customer admins, IT contacts, and implementation teams who want a clear explanation of what Azure Bridge is, what it does, and what is required to set it up safely.

What is Azure Bridge?

Azure Bridge is the TUDS-hosted Azure connection path for approved Vista SQL workflows.

TUDS hosts the connection layer in Azure. Customers configure Azure Bridge in Mission Control → Team Settings → Connectors → Azure Bridge and do not install bridge or tray software in their own environment.

Why does TUDS use Azure Bridge?

TUDS uses Azure Bridge when a team needs SQL-backed Vista workflows without exposing SQL Server directly to the internet.

Azure Bridge exists so that:

• TUDS hosts the Azure connection layer — no customer-side bridge installation
• approved SQL operations run through controlled private Azure services
• SQL credentials are stored in Azure Key Vault, not on customer machines
• customers retain control of SQL Server, SQL accounts, database permissions, and network approval

Does Azure Bridge expose our SQL Server directly to the internet?

No. SQL Server is not the public integration point.

TUDS traffic enters through Azure Front Door Premium + WAF, passes through a private relay, and reaches a private SQL execution service that connects to SQL Server using credentials stored in Azure Key Vault.

What is the Azure Bridge architecture?

The connection path is:

TUDS API -> Azure Front Door Premium + WAF -> private Azure TLS relay -> private SQL execution/admin services -> Azure Key Vault and customer SQL Server

Azure Front Door Premium with Web Application Firewall is the only public Azure edge. The relay, SQL execution service, and credential-admin service are private.

What exactly does Azure Bridge do?

At a high level, Azure Bridge:

• provides a TUDS-hosted HTTPS entry point through Azure Front Door
• validates TUDS-issued requests at the private relay
• routes approved traffic to private SQL execution and credential-admin services
• connects to SQL Server using credentials from Azure Key Vault
• executes only approved read and write operations for enabled TUDS workflows

Is Azure Bridge just a generic open SQL tunnel?

No. Azure Bridge is not an unrestricted SQL passthrough.

Read and write access are separated into controlled lanes. Read-only SQL is restricted to approved read behavior, and more sensitive write actions require explicit permissions and narrower execution paths.

How is access secured?

Access is secured in layers: HTTPS, Azure Front Door Premium, WAF protection, a private relay, TUDS-issued request validation, an explicit allowlist of approved relay routes, private Azure services that are not publicly reachable, and protected credential storage in Azure Key Vault.

The public entry point is a controlled Azure Front Door edge — not a public SQL endpoint or a directly reachable relay App Service.

How are SQL credentials handled?

SQL credentials are entered during Azure Bridge setup in Team Settings.

TUDS stores credentials securely in Azure Key Vault through the private credential-management service. Credentials are not stored on customer machines or in the public-facing layer.

Can we use a least-privilege SQL account?

Yes. That is the recommended approach.

For most customers, the simplest setup is a single shared least-privilege SQL login with access only to the specific database capabilities required for the agreed workflows.

Can we map Azure Bridge usage to individual SQL accounts?

Yes. Azure Bridge supports both:

• a single shared SQL account
• individual mapped SQL accounts for per-user identity models

If there is no strong reason to start with per-user SQL identities, the simpler shared-account model is the recommended starting point.

Where is Azure Bridge configured?

Azure Bridge is configured in Mission Control → Team Settings → Connectors → Azure Bridge.

There is no Windows tray app or bridge service to install in the customer environment. All connection configuration and testing happen in TUDS Team Settings.

What does customer IT need before setup starts?

Before setup, customer IT should have:

• the SQL Server host
• the SQL Server port
• the database name
• the SQL username and password
• any required customer-side network approvals or allowlisting steps
• confirmation that the SQL account has the right level of access for the agreed workflows

What is the basic setup process?

The normal setup flow is:

1. Open Mission Control → Team Settings → Connectors → Azure Bridge.
2. Enter the SQL connection details and credentials.
3. Complete any required customer-side network approvals.
4. Run the connection test from the Azure Bridge tab.
5. Confirm at least one real Azure Bridge-dependent workflow succeeds.

How do we know setup is complete?

Setup should not be considered complete until all of the following are true:

• the TUDS-managed Azure connection services are healthy
• the connection test succeeds
• a real Azure Bridge-dependent workflow succeeds
• logs do not show blocking network, credential, or SQL permission errors

How do we validate Azure Bridge after setup?

Return to Mission Control → Team Settings → Connectors → Azure Bridge and run the connection test. Then confirm that a real Azure Bridge-backed workflow succeeds.

If issues persist, review Azure Bridge request history in Team Settings and work with TUDS support on any TUDS-hosted service errors.

What kinds of workflows depend on Azure Bridge?

Examples can include:

• refreshing company or metadata information
• SQL-backed reporting
• financial workflows that depend on SQL connectivity

The exact workflows depend on the customer's enabled TUDS features.

What if the connection test succeeds but a workflow still fails?

That usually means basic connectivity is working but SQL permissions, connection details, or workflow-specific requirements still need attention.

Typical checks include:

• SQL Server host, port, and database name
• SQL authentication mode and credentials
• firewall rules and customer-side network approval
• SQL permissions for the specific workflow being attempted

What logs are available if something goes wrong?

In TUDS, use Mission Control → Team Settings → Connectors → Azure Bridge to review connection status and run connection tests.

Azure Bridge request history and related diagnostics are available through Team Settings. TUDS also monitors the hosted Azure path through Azure diagnostics and Log Analytics.

Who usually owns Azure Bridge issues?

Azure Bridge issues are often shared between the TUDS team and the customer's IT team.

In general:

• TUDS typically owns Azure Front Door, WAF, the private relay, private Azure services, Key Vault integration, monitoring, and application-side workflow behavior
• customer IT typically owns the SQL Server environment, SQL accounts, firewall rules, and customer-side network approval requirements
• some issues require joint troubleshooting because the full path crosses TUDS-hosted Azure services and the customer SQL environment

Is Azure Bridge appropriate for security-conscious customers?

Yes. That is the intent of the design.

The customer-comfort position is:

• SQL Server is not the directly exposed integration point
• Azure Front Door Premium + WAF is the only public Azure edge
• the relay, SQL execution, and credential-management services are private
• SQL credentials are stored in Azure Key Vault
• write behavior is more restricted than a generic open SQL connection model
• customers retain control of SQL Server, accounts, permissions, and network approval

What is the simplest way to explain Azure Bridge to a customer?

Use this:

Azure Bridge is a TUDS-hosted Azure connection path that gives TUDS controlled, secure access to approved SQL capabilities without exposing the customer's SQL Server directly to the internet and without requiring any bridge software in the customer environment.