Upgrading to ScreenMeet for Salesforce v1.27: Migrating Away from Username-Password Authentication

Overview

Salesforce will soon deprecate the Username-Password OAuth flow for Connected Apps and has issued compliance requirements for all integrations using this method.

ScreenMeet v1.27 introduces a new OAuth-based authentication model that removes the dependency on a stored password and security token. This article guides existing ScreenMeet Salesforce customers through the steps required to migrate to the new authentication model after upgrading to v1.27 or later.

Salesforce Compliance Requirement

Salesforce has flagged the Username-Password OAuth flow as non-compliant and has notified affected orgs by email. Failure to complete this migration may result in authentication failures for the ScreenMeet integration. See Salesforce Help: 005232552 and Salesforce Help: 005225370 for details.

Prerequisites

Salesforce System Administrator access.
Access to the ScreenMeet Console at console.screenmeet.com.
Existing ScreenMeet Salesforce integration previously configured (Service Account user already created and configured).

Step 1: Install the v1.27 Package Upgrade

Install the latest ScreenMeet package from AppExchange before proceeding with any configuration changes.

Navigate to the ScreenMeet listing on AppExchange and click Get It Now.
Select your target org and follow the installation prompts.
Once installation completes, confirm the installed package version is v1.27 or later under Setup > Installed Packages.

Upgrade Does Not Break Existing Functionality

Installing v1.27 does not immediately change how the integration authenticates. Your existing username-password configuration will continue to work until you complete the migration steps in this guide. Proceed through the steps at a time that suits your change management process.

Step 2: Grant Connected App Access to the Service Account

The ScreenMeet Service Account user must have the ScreenMeet Connected App explicitly enabled on the custom system permissions permission set you created during initial setup.

Which Permission Set to Use

This step targets the custom permission set your Salesforce administrator created manually during initial setup, typically named ScreenMeet Service System Permissions.

It contains system permissions such as Apex REST Services and API Enabled.

This is not the managed ScreenMeet Service permission set installed with the package.

If your org used a different name, locate it by checking the permission sets assigned to your ScreenMeet Service Account user. For reference, see Service Account Setup.

In Salesforce Setup, navigate to Permission Sets.
Open your custom ScreenMeet Service Account permission set (for example, ScreenMeet Service System Permissions).
Click Assigned Connected Apps.
Click Edit.
Move ScreenMeet from Installed Connected Apps to Enabled Connected Apps.
Click Save.

Step 3: Grant Connected App Access to Agents, Supervisors, and Administrators

All ScreenMeet users who log in to the console or use ScreenMeet features within Salesforce must also have access to the Connected App. The recommended approach is to create a dedicated permission set for this purpose.

In Salesforce Setup, navigate to Permission Sets and click New.
Enter ScreenMeet Console Access as the label and click Save.
From the permission set overview, click Assigned Connected Apps.
Click Edit, move ScreenMeet to Enabled Connected Apps, and click Save.
Assign this permission set to all ScreenMeet agents, supervisors, and administrators.
1. This permission set can be included in a permission set group as well
2. Example: ScreenMeet Agent permission set + ScreenMeet Console Access permission set = ScreenMeet Agent Permission Set group.

Step 4: Update the ScreenMeet Connected App Policy

With Connected App access assigned to all users and the Service Account, update the Connected App policy to enforce the new authorization model.

This Step Activates the New Authentication Model

Saving this change is the point at which the username-password flow is disabled for the ScreenMeet Connected App. Confirm Steps 2 and 3 are complete for all users before proceeding.

In Salesforce Setup, use Quick Find to search for Manage Connected Apps.
Click ScreenMeet from the list.
Click Edit Policies.
Under Permitted Users, select Admin approved users are pre-authorized.
Click Save.

Step 5: Remove Password and Security Token from ScreenMeet Console

Version 1.27 no longer uses the Service Account password or security token for authentication. Clear these from the console configuration to complete the migration.

Open console.screenmeet.com and sign in.
Navigate to Organization > Settings and Policies > Salesforce Integration.
Verify the ScreenMeet Service Account username is correct.
Clear the Password and Security Token fields if populated.
Click Save.
Click Configure and Validate Salesforce Org to confirm the integration is functioning.

Password Never Expires Permission

The Password Never Expires system permission on the Service Account is no longer required in v1.27 and later. You do not need to remove it, but it is no longer a dependency for the integration to function.

Verification

After completing all steps, confirm the migration was successful:

The Configure and Validate Salesforce Org button in the console returns a success status.
An agent with the ScreenMeet Console Access permission set can log in to console.screenmeet.com via the Salesforce OAuth flow without errors.
Check the Salesforce Login History for the ScreenMeet Service Account user to confirm successful OAuth logins with no authentication failures.

If Configure and Validate Salesforce Org fails, verify the following:

The Service Account user has both the managed ScreenMeet Service permission set and your custom service system permissions permission set assigned.
The Connected App is listed under Enabled Connected Apps on your custom service system permissions permission set.
Login History shows OAuth attempts for the Service Account. If no attempts appear, the username entered in the console may be incorrect.