After updating an identity provider record, users can no longer log into the instance through this record.Issue After making even a minor change to an identity provider record, there is a requirement to test the change before saving the record by using the Test Connection button and completing an SSO authentication through the identity provider. After this, you can save the identity provider record. In some cases, this process may break the ability of users to authenticate into the instance using this identity provider record even though the Test Connection check was successful.ReleaseNew York OrlandoCauseUsing the Test Connection button changes the Signing/Encryption Key Password field value on the form. Then, once the record is saved, the functionality of the identity provider record is borken because the password is no longer correct. To verify this, check if the Signing/Encryption Key Alias on the identity provider record has been customized. By default, its value is saml2sp Check also the audit history of the identity provider record, and see whether the Signing/Encryption Key Password value was updated at the same time that the other unrelated change was saved. If this is the case, you're likely running into the issue described in this knowledge article concerning the Test Connection button.ResolutionIf you exported an XML of the identity provider record before making the change, you can reimport the XML record to restore the identity provider functionality. If you do not have an XML of the identity provider record and you know what the value of the Signing/Encryption Key Password should be, you can re-enter this password and save the record, although to be able to save the record without using the Test Connection button again, you'll need to use the workaround mentioned below in Additional Information. If you don't have an exported XML of the identity provider record and don't know the value of the Signing/Encryption Key Password field, you'll need revert the version of the identity provider record to the previous version before the change was made.Related LinksThis section describes a workaround solution that can be used to avoid the Test Connection button issue. You can temporarily add this system property to the instance: Name: glide.authenticate.multisso.test.connection.mandatoryType: true|falseValue: false Once this property has been added with the false value, you can save a change to the identity provider record without having to use the Test Connection button first. After making a change and saving the record, make sure that users can authenticate successfully into the instance with the updated identity provider record. IMPORTANT: After using this workaround, re-enable the Test Connection requirement because not having this requirement in place could lead to other broken identity provider issues in the future, which could be much more complicated. The Test Connection button has an important role to play in ensuring unintended changes aren't made to the identity provider record. 1. Find the system property you added named glide.authenticate.multisso.test.connection.mandatory2. Don't change its value from list; instead open the system property record in form view and change its value to true on the form.3. While still on the form, save or update the record.4. While still on the form, delete the glide.authenticate.multisso.test.connection.mandatory system property record.