Skip to content
Thirdlane

Connect Provisioning

Thirdlane Connect is the softphone and messaging client your users run. It comes in three forms - a web app served by the PBX, a desktop application for Windows and macOS, and a mobile app for iOS and Android. This page covers how users get each one and how each one learns which server to talk to.

Why this matters

Every Connect client has to be told the hostname of the PBX it belongs to. The web app never asks, because it was loaded from the server and already knows. The desktop and mobile apps are installed from elsewhere, so on first launch they have to find out - either the user types the hostname, or the app was built with the hostname already in it.

That single question - who types the hostname, and how - is the main thing to plan before a rollout, because a mistyped hostname is the most common onboarding failure.

The server address is a property of the app build, not something a device management platform can push. There is no registry key, settings file, or managed app configuration that pre-seeds it. See Pre-configuring the server address below.

Web client

The web client needs no installation. Users open the PBX hostname in a browser:

https://pbx.example.com/connect/app/

It reads its server from the address it was loaded from, so there is nothing to configure and nothing to distribute beyond the link itself.

Requirements:

  • A browser that supports WebRTC, which Connect uses for calls.
  • HTTPS with a certificate that browsers trust. Connect uses WebRTC, and browsers refuse microphone and camera access over an untrusted connection - a self-signed certificate lets sign-in appear to work while calls have no audio. See Domain and SSL Certificate.

Desktop client

The desktop client is an installed application with system tray presence, native notifications, screen sharing and native audio device handling.

Where users get it

The PBX serves the installers at /downloads/thirdlane-connect/, and both the Manager dashboard and Connect’s own Downloads screen link to them directly, so in most deployments you simply point users at one of those.

PlatformPackage
WindowsInstaller (.exe)
macOSDisk image (.dmg)

The files are served from /srv/thirdlane/www/thirdlane-downloads/thirdlane-connect/ on the PBX.

First launch

The login screen shows a Server field. In the standard build the user enters the PBX hostname (for example pbx.example.com). The choice is remembered and pre-filled on later launches, so it is asked once per machine.

Updates

Updates are not silent. The server tells the client which build is available, the client compares that against its own build number, and if the server has a newer one the app shows that an update is available. The user then downloads the installer from the PBX and runs it. Nothing installs itself in the background, and no external update service is contacted - the installer comes from your own PBX over HTTPS.

Mobile client

The mobile client is published on both public app stores. Users install it the same way they install anything else on their phone:

Because it is a public store app, there is nothing to distribute and no sideloading or “unknown sources” permission to enable. On first launch the user enters the PBX hostname, exactly as on the desktop.

If your device management platform installs store apps for you, that covers installation only. The app reads no managed configuration, so the server address still has to be entered by the user or built in.

Pre-configuring the server address

If you do not want users typing a hostname at all, the server list has to be compiled into the app. Two build-time settings control this:

  • An allowed server list - a fixed list of hostnames. When set, the login screen shows them as a Server dropdown with the first one already selected. A list with one entry means the user never chooses anything.
  • Permission to enter another address - whether to also offer “Enter your own server address…”, which reveals a free-text field. Turn it off to restrict the app to the listed servers only.

Neither is set in the standard builds, which is why they ask. Both apply to the desktop and mobile apps in the same way.

Changing them requires a build of the app, so this route is part of the OEM and whitelabel path described below rather than something you can configure on the PBX or push to devices. When a build ships a fixed server list, the app does not persist a per-user server choice - the list is the configuration.

Whitelabeling

Basic customization (self-serve)

Available to every customer from the Manager, with no build required and no source access. Connect Branding sets the app name, logo, favicon and primary color, applied to the login screen at runtime. Tenant branding adds per-tenant logo and color overrides. Changes take effect as soon as they are saved.

Deep customization (OEM)

Changing the installed app’s own identity - its name in the operating system, its bundle identifier, its store listing, or a built-in server list - cannot be done at runtime, because those values are baked into the package that gets signed and published. That needs a build from source:

  • Desktop - the application name shown by the operating system and the identifier it registers under.
  • Mobile - the app name and bundle identifiers used for the iOS and Android store listings.
  • Web - the path the app is served under, for deployments that host it somewhere other than /connect/app/.
  • Both desktop and mobile - the built-in server list described above.

Contact your account team for access to the build pipeline.

Worked example: roll out Connect to a 40-person office

The company PBX is at pbx.acme.com. Staff use Windows laptops and their own phones.

  1. Confirm the certificate. Open https://pbx.acme.com/connect/app/ and check it loads without a certificate warning. A self-signed certificate breaks WebRTC audio even though sign-in succeeds, so fix this before anyone installs anything.
  2. Apply branding. Set the app name, logo and color in Connect Branding so the first login screen users see is Acme’s.
  3. Desktop. Point staff at their user dashboard, which links the Windows installer, or push the installer with your management tool. Either way they enter pbx.acme.com once on first launch and it is remembered.
  4. Mobile. Tell staff to install Thirdlane Connect from the App Store or Google Play and enter pbx.acme.com. If phones are managed, push the store app so it is already installed.
  5. Web for shared machines. Contractors and shared desktops can use https://pbx.acme.com/connect/app/ with nothing installed.
  6. Put the hostname in the welcome email. Since every installed client asks for it once, the hostname in writing - copyable, not transcribed from a screenshot - is what prevents the typo tickets.

Users then sign in with their extension credentials, or through SSO if you have configured an identity provider.

Best practices

  • Always serve Connect over HTTPS with a trusted certificate. A self-signed certificate produces calls with no audio while sign-in still works, which is difficult to diagnose from the symptom.
  • Send the hostname as text. Every installed client asks for it once, and a copyable hostname in the welcome email removes the most common onboarding error.
  • Prefer the web client for shared and unmanaged machines. It needs no install and no hostname entry.
  • Brand before you distribute, so the first login screen users ever see carries your identity.
  • Plan a fixed server list early if you need one. It requires a custom build, so it is a procurement decision rather than a setting to switch on later.