As Kognitiv Loyalty evolves, so does the methodology for platform and instance access. Whether users log in through a third party application or directly into Kognitiv Loyalty itself, the system has changed the way it understands logins and user access.
Breaking this down can get complicated, so we've created a series of visualizations and explanations to define Enterprise Administration and User Management.
Eventually, this is the core visualization you'll understand. It's the basis for how login and user management works on Kognitiv Loyalty and within instances.
Welcome to Tie Town
In order to get this process moving, let's look at a fake company. We'll call them Tie Town. Tie Town is a new client that wants to have access to Kognitiv Loyalty and two separate instances. One instance will be for Quality Assurance (QA) and testing and the other will be the official Tie Town production instance with real customers and information. Tie Town wants their employees to use one login to get into all of their Kognitiv Loyalty instances.
When it comes to the visualization referenced above, Tie Town is the Enterprise.
We won't configure Tie Town this way, but it's essential to understand the role of an identity provider when it comes to logging into Kognitiv Loyalty. An identity provider, at its very basic level, proves the authenticity of a user when they attempt to log in. This can happen locally with a username and password combination in Kognitiv Loyalty, or Kognitiv Loyalty can seek the authentication from a third party identity provider.
Tie Town could, hypothetically, have their own network of employee facing, individual web applications, like email, a message board, document sharing and a company directory. When Mary Smith sits down at her desk in the morning and logs into her Tie Town customer service account, she could see this slew of web apps. If configured for Single Sign-On, her initial morning login means that she can hop into applications without entering her username and password each time.
Kognitiv Loyalty access can be configured in the same way. If Tie Town wanted Kognitiv Loyalty to appear in that list of web applications when Mary Smith logs on in the morning, they could set it so that Kognitiv Loyalty checks with their identity provider to validate the authenticity of a user and log them into the platform.
What is an Enterprise Admin?
As with all clients, Kognitiv Loyalty Support will create the first user and give them the Administrator security role and make them an Enterprise Administrator. From there, it's up to this Tie Town team member to add more logins and connect them to individual instances as users.
The Enterprise Admin manages logins. They create logins and passwords for people who need to access Kognitiv Loyalty. They'll bind email addresses to identity providers, whether that's the local Kognitiv Loyalty or some third party like Tie Town.
Back to Mary Smith at Tie Town. The Enterprise Admin wants to add Mary to the Tie Town QA and Production instances. First, the Admin will add that login to Kognitiv Loyalty. This action does not get Mary Smith into any instances. Sure, Mary Smith can log in now, but this is the screen she'll see.
Not very useful, right?
Mary's login works, but she hasn't been added as a user. That takes another step.
The Enterprise Admin work stops here. Getting Mary into individual instances falls under a different portion of Kognitiv Loyalty entirely.
This is System User Management
When Kognitiv Loyalty Support team spun up the Tie Town account and started their QA and Production instances, they created a login and user with the Administrator security role and made them an Enterprise Administrator. That person used their Enterprise Admin abilities to make Mary Smith a login, and she has access to Kognitiv Loyalty. Now they want to add her as a user on individual instances.
Adding System Users can be done by anyone with the right System User Security Roles. That initial Administrator Kognitiv Loyalty Support made for Tie Town has the right Security Roles to get Mary Smith in both instances. Any user can have those same Security Roles, too. The Security Roles page in the application is powerful enough to give (or deny) users access to individual pages in the platform, from creating users to managing member enrollment.
That Administrator will need to head into both the Production and QA instances, navigate to the System > User menu and add Mary Smith as a user on each. By matching Mary's login email to the one they used to create her login, she'll have proper access.
Now Mary Smith is a user on both of Tie Town's instances.
Enterprise Admin vs. Login vs. User
Let's put it all together. In our example, Tie Town is the enterprise.
- The first user Kognitiv Loyalty Support created for Tie Town had the Administrator security role and was an Enterprise Admin.
- Our Enterprise Admin created Mary Smith's Login, giving her access to Kognitiv Loyalty but no instances.
- Then our user with System User Security Roles added Mary to both the Production and QA instances for Tie Town as a User.
Finally, here's our visualization with Tie Town in place.
