User Authorization

There are different authorization scenarios you may encounter when using

Sometimes it doesn't matter if you know who is who. Sometimes you want to make sure people aren't voting again and again to game the system. Sometimes you'll want total transparency. Maybe you already know who your users are. Maybe you even have your own authorization system.

Polis handles all these cases. Here's how.

Optional social login


By default, participants can write and vote anonymously, but are prompted to sign in using Facebook and Twitter. This is low friction for users and encourages voting and writing.

Social login required to write >> Config >> User login required to write >> ON

Social login required to vote >> Config >> User login required to vote >> ON

Social login prompts disabled

In this scenario, users who have already validated a social profile will still be shown. No users will be prompted to connect their social profile >> Config >> User shown social login >> OFF

Completely Anonymous

In this scenario, even users who have already validated a social profile will not be shown. The visualization is hidden. >> Config >> Total Anonymity for All Users >> ON

Anonymous but verified via social account login

In this scenario:

  • All users are prompted to connect social before voting and / or writing
  • The visualization is hidden and no user identities are passed on to you as the owner.

This scenario is ideal if:

  • You need to ensure that users are not gaming the system
  • Possibly collect metadata from the accounts like a restricted geolocation
  • Ensure that identities remain secret. >> Config >> Anonymous but verified with social account >> ON

Proprietary auth

This scenario is only available if the conversation is instantitaed through an embedded <iframe/> on your page. You'll decide whether or not the user is verified. You can then use the per user config data attributes to customize the experience at will.

A nice pattern is to shut off writing and voting for those not logged in. Users who are not logged in can still consume a read-only version of the conversation by clicking through the visualization.


Creating custom URLs for each participant to join

This feature is coming soon.

Let's say you are a business intelligence analyst, and a hospital has hired you to run a survey of its doctors and nurses. Conveniently for the purposes of our example, they've asked you to use

In this scenario, the hospital has an employee database. They would like to correlate employment data - columns like role, length of employment, age, gender, etc. - with groups that emerge in

You are going to send out links because the hospital will not be embedding the conversation on its site and has no template and authorization system, but it's not appropriate to have doctors and nurses connect Twitter and Facebook.

In this case, you'll want to create a URL per participant, with a key that you can use to map them back to the data you already have about them. When we make this feature public, we'll fill the rest of this in!

results matching ""

    No results matching ""