Restricting Case Creation while Allowing Assignment Processing

The Scenario

What if I want to stop a person creating? But allow them to work on cases?

A very common enterprise requirement is segregating duties: you have a specific Persona (let’s call them “Tour Operators”) who need to process assignments, update data, and move a case forward, but they should not be allowed to initiate or create that case type themselves. Another Persona (e.g., “Customer” or an API) handles creation of Customer Feedback.

Prerequisites

For this walkthrough, assume we have:

  1. This has been written and tested in Infinity '26.

  2. A Case Type named Feedback collections.

  3. A Persona named Customer (who can create the case).

  4. A Persona named Tour Operator (who can work on the case once created).


Step 1: Configure Persona Authorizations in App Studio

Blueprint will handle most of this for you when you Import your Personas. However, Blueprint only addresses wholistic “case” or “data” access. It does not address more detailed security requirements at the assignment/task level (yet).

We can handle this entire security requirement without writing a single rule manually.

  1. In Dev Studio, navigate to Security > Access Role Name

  2. Select the Tour Operator Managed persona to open their access rights.

  3. Under the Case types section, locate the Feedback Collection case.

  4. You will see checkboxes for standard actions: Read, Write and Delete Instances

  5. Update the Write instances permission to a when rule of your choice

When rule creation

In my scenario, I am going to allow Tour Operators to edit the case so long as its not during creation. However, your scenario may be different so please implement security rules according to your requirements

Have another way to do this? There are many. Please share how you would approach it in the comments below :backhand_index_pointing_down:

  1. Type in name of new when rule, “IsNotCreateStage”
  2. Click the bullseye to open the rule
  3. Create the rule
  4. Apply the logic: Is not create stage (PRIM0) and ID exists.
    1. Both these are required to protect the Create menu and the Open Assignments after case is created
  5. Click save

Step 2: What Happens in the Constellation UI?

Because Constellation’s UI components are deeply integrated with Pega’s security model, the portal updates automatically:

  • The Create Menu (+): When a user with the Tour Operator persona logs into the Constellation web portal and clicks the global “Create” (+) button, the Feedback Collection case type will be completely hidden from the list.

  • The Worklist/Queue: If a Customer creates an Feedback Collection case and routes an assignment to the Tour Operator, they can still click on the assignment, open the case, view the summary panel, and submit the action.

Because the “Write” permission is maintained, the Worker can still save data to the clipboard and commit the assignment to the database, cleanly separating the Create stage from the processing stages.


Key Takeaway :pushpin:

In Pega Constellation, you rarely need to modify UI elements to hide case creation options. Secure your application at the data and authorization layer (via Personas in App Studio), and the Constellation portal will automatically render the correct UI for the user.

Additional Resources


Enjoyed this article?

See suggested articles from our Constellation 101 series and view all our Knowledge Shares from our User Experience Expert Circle.

5 Likes

In Dev Studio, go to Security > Access Role Name and open the Tour Operator persona’s access rights. Find the relevant case type and locate the Write instances permission. Change that permission to use a “when rule” — create a new rule called IsNotCreateStage with the logic: the stage is not the Create stage AND a case ID already exists. This rule blocks Tour Operators from creating the case themselves while still letting them open and process assignments routed to them. Because Constellation’s UI is tied directly to these security settings, the case type will automatically disappear from the Create (+) menu for Tour Operators, with no manual UI changes needed.

1 Like

HI @MarcCheong, I have a similar requirement in Pega Constellation. I am using version 25.1.2. A user from work portal clicks on global “Create” button to create a case and it is waiting to create and load the assignment. Meanwhile that user has again clicked the create button hence it creates another case. Hence, our requirement is to restrict the user from creating the same case again if the assignment is still loading. So, I have tried the approach mentioned in this article, but when I add a Access when (IsNotCreateStage) with same conditions to the Access role name under relevant case type “Write instances”, the global create button itself gets completely hidden. The User access role has only one case type that he/she can create from work portal. Are there any other approach or suggestions to identify this issue.

I’m curious why the assignment load is so slow the user is tempted to create another case? When you create a case, you are navigated to that case, so really there should be no opportunity to then create a new case.

That aside, this article was more written where the requirement was to stop a certain persona from creating cases full stop. In this scenario it is a bit more nuanced and I’m not sure that ARO is the way to go.

It seems like you are trying to prevent duplicate case creation? You could just use the standard approach to Finding duplicate Cases?

1 Like

Thank you for sharing this article. Could you tell me how does the condition works to not to display the case type under the Create Menu (+)? With just .pxCurrentStage!=PRIM0, it it still displaying the case type, but with .pxCurrentStage!=PRIM0 && .pyID!=“” it is not displaying the case type. How does this condition get evaluated even before case creation?

How does the visibility works on the Create menu? With the condition pxCurrentStage!=PRIM0, it shows the case type to the Tour operator, while by adding .pyID!=“”, it doesn’t show. When does this condition get evaluated?

@RaghuveerReddyB the problem with using .pxCurrentStage!=PRIM0 is when a case doesn’t exist yet, it has not current stage so actually this evaluate to true :frowning:

I added the pyID existing arguement, so that we check if there is a case and its not in create stage, then this allows them to process that assignment.

There are probably other ways to do this, but I found both these arguments worked for the scenario I outlined.