Not every visitor to your Power Pages site is the same. Some are customers, some are partners, some are staff. They come for different reasons, and they need different help. So why give them all the same chat agent? A customer asking about an order does not need the same Copilot Studio agent that a partner uses to check contract details. With a bit of setup, you can show the right agent to the right person, based on who they are. The key to all of this is the web role.
In this guide I will show you how to display different Copilot Studio agents on your Power Pages site depending on the visitor’s web role.
What a Web Role Is
A web role in Power Pages is a label that says what kind of user someone is and what they are allowed to do. You might have a role called Customer, another called Partner, and another called Employee. When a person signs in, the site checks which roles they belong to and uses that to decide what they can see.
Web roles are the backbone of access control on a Power Pages site. They already shape which pages and records a user can reach. We are simply going to use that same idea to control which agent shows up in the chat. Once you set your roles up well, the rest is easy.
Why Show Different Agents at All
You might wonder if this is worth the trouble. In many cases it really is. Each Copilot Studio agent can be tuned for a specific audience. A customer agent can be friendly and focused on orders, returns, and account help. A partner agent can dig into deals, pricing, and shared documents. A staff agent can answer internal questions that no outside visitor should ever see.
If you tried to cram all of that into one agent, it would get confusing fast. The agent might share partner info with a customer by mistake, or bury a simple answer under a pile of choices. By giving each group its own agent, you keep every conversation clean, safe, and on point. The visitor gets help that feels made for them.
The Tool That Makes It Work
Power Pages uses a template language called Liquid, and Liquid can read the signed-in user’s web roles. This is the trick that lets you pick the right agent. There are two simple ways to check a role.
The first is the contains check. You look at the list of the user’s roles and see if a certain role is in there:
{% if user.roles contains 'Partner' %}
<!-- show the partner agent -->
{% endif %}
The second is the has_role filter, which checks for one role in a clean, readable way:
{% if user | has_role: 'Employee' %}
<!-- show the employee agent -->
{% endif %}
Both do the same basic job. Use whichever feels easier to read. The point is that you can ask the page, “Does this person have this role?” and then act on the answer.
Putting the Agents in Place
Each Copilot Studio agent has its own embed snippet that you drop onto a page to make the chat appear. To show different agents by role, you wrap each snippet in a role check. The page then loads only the snippet that matches the visitor.
Here is how the whole thing can look when you stack the checks together:
{% if user %}
{% if user.roles contains 'Employee' %}
<!-- Employee Copilot Studio agent embed code -->
{% elsif user.roles contains 'Partner' %}
<!-- Partner Copilot Studio agent embed code -->
{% else %}
<!-- Customer Copilot Studio agent embed code -->
{% endif %}
{% else %}
<!-- Optional: a basic public agent, or a sign-in prompt -->
{% endif %}
Read it from the top down. First the page checks if the visitor is signed in at all. If they are an employee, they get the employee agent. If they are a partner, they get the partner agent. Everyone else who is signed in gets the customer agent. And if the visitor is not signed in, you can show a simple public agent or just ask them to log in.
The order matters here. The page checks each condition in turn and stops at the first match. So put your most specific roles near the top and your catch-all option at the bottom.
Handling People With More Than One Role
Real users sometimes hold more than one role. A person could be both a Partner and an Employee. Because the checks run in order and stop at the first hit, the role you list first wins. So think about which agent should take priority when someone fits two groups, and place that check above the others. A little planning here saves confusion later.
Keep It Safe, Not Just Hidden
It is worth saying clearly that hiding an agent with Liquid is mostly about showing the right experience, not about locking down secrets. The Liquid check keeps the wrong agent off the page, which is good for a clean experience. But the real security for your data should live in the agent itself and in your table permissions. If your partner agent can reach sensitive records, protect those records with proper permissions so that only partners can ever pull them. Treat the role check as the friendly front door and the permissions as the real lock.
Test Each Role Before You Launch
Once everything is wired up, test it with a real account for each role. Sign in as a customer and confirm you see the customer agent. Sign in as a partner and check for the partner agent. Do the same for staff. Then try a fresh, signed-out visitor to make sure your public option behaves the way you want.
If you have users with two roles, test one of those accounts too, so you can confirm the priority you set actually plays out. Open the pages in a private browser window now and then, since that helps you see the site the way a brand new visitor would.
Wrapping Up
Showing different Copilot Studio agents by web role comes down to a simple idea. You already know who your visitors are through their roles, so you use that knowledge to hand each group the agent built for them. Web roles tell you who is who, Liquid checks those roles, and the matching agent snippet loads on the page. Add solid permissions behind the scenes, test every role, and you end up with a site where each visitor meets a chat agent that feels made just for them.