Talkative supports using Azure AD as an Identity Provider using JIT provisioning or via our SCIM API. Setup should take no longer than 10 minutes and will enable users within the authenticated application to log in to Talkative.

This integration will require a new Enterprise Application. To start, create a new non-gallery application from within the portal.

Select "Single sign-on" from under the Manage header on the left of your screen and choose "SAML" as the single sign-on method.

This will present you with some SAML configuration options. Scroll down to the SAML Signing Certificate section and download your Federation Metadata XML file. Keep this file somewhere safe, as we will require it in the next step.

There is a known issue when downloading the Federation Metadata file from Azure. In some cases, the first file provided will be invalid and will cause login failures. If you receive a SAML error when logging into Talkative, please repeat the process and download a new Metadata XML file. 
As a potential shortcut, you can fill the Reply URL and Entity ID with junk data and then refresh the page and reattempt the XML download. The most common way to identify failure is if it takes more than a few seconds for the file to generate.

Login to talkative as an account holder and load the "Company Manager" from the Settings menu. In the top right-hand side of this screen, you will see the option to "Add Single Sign on Provider".

Next, choose Azure AD/Salesforce from the SSO Provider dropdown menu, enter a server label. This label must be one word, with no spaces, and unique. The label can be used to generate a shortcut to login and also provide a sign on URL to fill in your Active Directory Enterprise application. For example, if you chose the label mycompany, you could load https://{yourregion} - and your users will be automatically taken to the SAML sign on page, instead of having to first enter their email in Talkative Engage.

There is a tick box labelled JIT. If you choose this, Just in time provisioning will be enabled, which means upon the user's first login to the Talkative Engage system, and account will be provisioned for them. Please note, the account generated will have no queue or group configuration, so a supervisor or account holder would then have to add them to the appropriate groups for them to accept interactions.

If JIT is not enabled, an account holder or supervisor would have to create an account manually in Engage for the user, or your Azure Active Directory administrator would need to integrate with your SCIM endpoints to enable automatic provisionng and de-provisioning of user accounts.

Finally, click browse to find your Federation Metadata file and upload it here.

If successful, you will be redirected to the SAML Settings page for this server. On this page, you will be provided with a Relying Party Trusts Identifier and a SAML Endpoint. Add these values to the Active Directory SAML Configuration.

Mapping User Attributes & Claims

Talkative Engage maps internal roles to Azure Security Groups or Azure Roles. Depending upon which method you choose, different claims will need to be provided. The claims required are as follows:

Azure Security Group Based Permissions

Claim NameValue user.groups [ApplicationGroup] user.mail or user.userprinciplename

Azure Role Based Permissions

Claim NameValue user.assignedroles user.mail or user.userprinciplename

Group based permissions has a maximum claim length of 2048. If you have viewed this guide before, the user.groups claim returned all user groups. The recent change has changed this to only return groups relevant to the enterprise application.

Mapping Talkative Permissions via Security Groups

Talkative has three user levels. Agent, Supervisor and Account Holder.

Create three user groups within Azure Active Directory. Suggested names are Talkative Agent, Talkative Supervisor and Talkative Account Holder, but you can name these whatever you like, or if there are suitable pre-existing groups, these can also be used. As part of the claims, we will receive the Object ID of the groups the user is a member of. 

These object IDs can be mapped to roles within the Talkative SAML configuration page:

Mapping to a group here will allow us to identify which role the user should be granted.

If the user is a member of multiple role groups, the system will seek the highest permission to assign to the user. So if a user was a member of the Agent and Account Holder group in Active Directory, they would be assigned the role of Account Holder in the Talkative Portal.

Permissions can be mapped to multiple groups in Active Directory, to map more than one group to one permission, enter the Object IDs separated by the pipe character (|).

Once you have mapped your permissions, click "Update Permission Mapping" to save the settings.

Mapping Talkative Permissions via Roles

Just like above, the three talkative permission sets can be mapped to a role inside Active Directory. As before, assign the relevant roles to the users in Active Directory, and then map them appropriately inside the permission mapping.  Multiple Azure roles can be mapped to a single permission in Talkative Engage by separating them with a pipe character as is the case with groups.

Authorised Domains

To allow users to login, you must authorise the domain names of the email addresses they will be using to log in. 

If a user was logging into the system using their email,, you will need to enter into this form.

Sign on URL

An optional setting from within Azure Active Directory is the Sign on URL. Adding this will show the application within the "My Applications" portal and allow users to click straight through to the login page for Talkative.

The value for this is dependant upon the instance region you are using. For example, the URL for the EU instance would be - replace the eu with the region you are located in (us, au, or eu).