Pega does not give you a sign up screen out of the box.
If you are building an internet-facing application where real customers need to register themselves, you have to build it. This video walks through exactly how to do that – from the screens to the operator creation logic.
Before I get into the steps, one important distinction worth making. If your application is intranet-facing – used by bank employees or internal teams – you almost certainly do not need a sign up screen. Single sign-on handles operator provisioning automatically in those cases. Sign up screens are for internet-facing applications where external customers are creating their own accounts.
What We Are Building
Three screens connected together. A login screen with a sign up link added to it. A registration form capturing username, password and email. And a confirmation screen once the account is created.
Behind the scenes, an unauthenticated activity takes those inputs and creates a new operator ID in Pega.
The Key Concept – Unauthenticated Activities
This is the part that most tutorials get wrong.
When a user is on the sign up screen, they are not authenticated. That means any activity you call from those screens must be explicitly marked as unauthenticated – require authentication must be disabled, and allow invocation from browser must be enabled.
You also need to create a privilege for these activities and add it to your unauthenticated access group via a custom access role. Skip this and you will hit authorisation errors that are painful to debug.
Never hard code a username and password into your HTML rules to get around authentication. Instead, pass pzauth=guest as a query string parameter. That is the right approach.
Linking Screens With Activities
The way screens connect in Pega’s unauthenticated layer is through form submissions. Each HTML rule has a form tag with an action pointing to the server URL, and a hidden input with pyActivity pointing to the activity name you want to execute.
When the user clicks a button, the form data – including the activity name and any input values – gets submitted to the server. Pega’s engine reads the pyActivity parameter and executes that activity. The activity then uses soHTML to render the next screen.
Understanding this mechanism is the key to building any kind of multi-step unauthenticated flow in Pega.
Creating the Operator
Once all the screen navigation is working, the final step is creating the operator from the registration form inputs.
Rather than trying to reuse the standard operator creation activities – which require authentication – you build a custom unauthenticated activity. You can still call the check keys activity inside it to validate for duplicates, and set a status message that gets passed back to the HTML rule to display success or error feedback to the user.
A Few Tips From Building This
I hit a number of issues building this and want to save you the same pain.
Always use div tags in your custom HTML, not table tags. Build your HTML locally first and test it in a browser before putting it into Pega. Use the remote tracer to debug unauthenticated sessions on the server. Use the browser Network tab to verify what form data is being submitted. And make sure your unauthenticated access role has read access to the rule-obj-class to avoid unexpected authorisation errors.
Watch the Full Walkthrough
In the video below I build the entire sign up flow from scratch – all three screens, the unauthenticated activities, operator creation, duplicate validation and error handling.
This is a genuinely useful capability for any internet-facing Pega application. The video covers every obstacle I ran into so you do not have to.
