No Status

Allow Engagement Audience logic to override KC bot Audience logic if used in KC bot

  • 11 January 2021
  • 3 replies

Userlevel 3

Posting on behalf of customer,

          Whenever user selects Audience rules in engagement to restrict it to only particular set of audience, it would be displayed to only that set of audience when Triggered by is set to Automatic.

          Instead if the Triggered by is set to Knowledge Center, the Knowledge center Audience Logic rules overrides the Audience logic of engagement.

          Example Scenario: If in Engagement audience logic, it is selected to be shown to only particular account users. But in KC bot, if audience logic is set to be shown to all users. In this case, Engagement is being shown to all the users of all accounts. 

          Instead if the engagement is shown to only users who are selected in Engagement audience logic, it would be of great help instead of creating multiple KC bot’s for each required filter at engagement level.

3 replies

Userlevel 7
Badge +2

@GunaShekar Vudarapu Thanks for bringing this up here! I am redirecting the to the product team for more visibility.

Userlevel 1

I’d like to add additional reasons for needing this functionality. We have two main types of segments we use in our audience logic - the production instance for our client accounts and the user type for our individual users. For example, we release on different schedules for some accounts versus others, making a production A and B. We also have content targeted to just our application administrators, versus all other users.


It is not manageable or realistic for us to have 4 different KC bots that we have to maintain in order to properly segment engagements we want to show our users - production A, production B, app admins, and all users. We need the audience logic from the engagements to carry over into the KC Bot.

Userlevel 3

+1 here too, thanks for submitting


We have a KC Bot destined for prospects in evaluation and customers.  Which is perfect for managing because it makes sense for the bots in those cases to be different.


Though, we have certain engagements planned that are audience scoped by which AWS Cluster the account has been onboarded and these engagements include specific onboarding information like IP addresses, etc.  These engagements are useful for both prospects and customers, but for me to ensure the engagement is properly targeted and visible, if I have 6 AWS Reference Information Engagements, that’s now 12 separate KC Bots i’d need to manage.


Another use case is we built a engagement that makes it easy to schedule 1:1 time with our Sales Engineers calendars (via iframe to scheduleonce).  Though this would only be available to customers over a certain ACV.  This along with the above would just simply continue to multiply the amount of KC Bots i’d need to manage to achieve something that’d be simply resolved if the KC Bot respected the Audience logic of the engagement.