Whenever someone views your website, the platform recognises them as a user - even if they aren't logged in.
Anonymous Users
Before talking about logged-in users we should look at everyone else. Most of the pages on your website probably aren't secured. They are published to the internet and (IP restrictions aside) can be accessed by anybody, anywhere in the world. When someone visits your site the platform treats them as Anonymous until they log in. In fact, you are the anonymous user right now while you are reading this article.
The anonymous user is actually a website user in the platform. It should have the username "Anonymous" and not very much else. There won't be a profile and it won't ever be used to log into your site. The anonymous user will be in a single group, normally called PUBLIC, all by itself.
Why bother with an anonymous user for everybody?
As you'll see later, the platform expects forms and processes to be started by somebody, so by having an anonymous user, we can handle requests submitted by anybody.
Users
When someone registers with your website, or logs in for the first time using a third party provider, they get an account in the platform.
Accounts have a "username" which is a unique identifier that never changes. This identifier is not used for logging in.
Each account has one or more logins associated with it. Logins hold the username and password your users actually log in with. They could be created when someone registers directly with your site, or when someone logs in using Google, Facebook, your corporate ADFS, or another provider.
By separating accounts and logins, users can update their login username, and add or remove third party providers from their account, but still be recognised as the same user by the platform.
User Groups
Users are organised into groups. When a user first logs in they are added to a default group that contains all of your users.
You'll probably want to create additional user groups so you can secure content that regular users shouldn't access. Sites often have at least one staff user group, and most have many more, organising staff users into different teams and departments, allowing different content to be secured to different people, and different services to be managed by different sets of users.
You can read more about creating users and groups in the Site Groups and Users documentation.
How are Groups and Users Used?
Securing Content
Articles and media items on the platform are secured to user groups. If a user tries to access secure content, they'll be prompted to log in. Once they've logged in, they'll then be redirected to the content they were trying to access.
Starting Processes
Process models manage the workflow of tasks and interactions that make up the services delivered by your site.
Processes are started by users, known as candidates. When you create a workflow model you can pick the users, or groups of users, who will be able to start it. In most cases this will be the default user group that all of your users are in. You might also include the anonymous user as a candidate, so the request can be started by users who aren't logged in.
Workflow Process Tasks
During a workflow process you'll probably need a member of your staff to, at some point, review what's going on or reply to the person who raised the request.
User tasks in a process model are carried out by named users. They can be assigned directly to users, or be sent to a group of users for one person in that group to carry out.
These tasks are handled using the Self Service template.
History and User Data
When users interact with your services, the platform's History Service can be used to record a log of events. Events record the user who created them and information about what happened.
For example, if a staff member replies to a request, an event could be logged in the history of that request, recording the date and time of the reply, and the username of the staff member who sent it.
Share this page
