Pendo Login Settings: How to Set Up SSO and SCIM – Thoughts about Product Adoption, User Onboarding and Good UX

What Are Pendo Login Settings?

Pendo login settings are the administrative controls that determine how internal users access Pendo. In a simple setup, users might sign in with an email address and password. In an enterprise setup, teams usually prefer SSO, where users authenticate through a central identity provider such as Okta, Microsoft Entra ID, Ping Identity, Google Workspace, or another IdP that supports SAML.

For larger organizations, authentication is only half the story. The other half is provisioning: creating, updating, and removing user access automatically. SCIM, short for System for Cross-domain Identity Management, helps identity providers synchronize users and groups with SaaS tools like Pendo. In plain English, SSO answers, “Who are you?” while SCIM answers, “Should you still be here, and what should you be allowed to do?”

That combination is powerful. SSO reduces password fatigue and centralizes authentication policy. SCIM reduces manual work and keeps access aligned with team changes. Together, they make Pendo easier to adopt, easier to govern, and far less likely to turn into a spreadsheet-powered access circus.

Why SSO and SCIM Matter for Product Adoption

Product adoption is often discussed in terms of activation, onboarding flows, sticky features, habit loops, and user engagement. That is all valid. But internal adoption of a platform like Pendo also depends on operational friction. If a product manager has to wait three days for access, a customer success manager gets the wrong role, or a UX researcher cannot view the dashboard they need, adoption slows before the first chart loads.

Good login architecture supports adoption in three practical ways. First, it lowers the barrier to entry. Users can access Pendo using the credentials they already trust. Second, it improves confidence. Admins know access is governed through a central source of truth. Third, it supports scale. When teams grow, reorganize, or change responsibilities, permissions can follow groups instead of relying on one heroic admin who remembers everything and definitely deserves a vacation.

In short, Pendo SSO and SCIM are not just security features. They are onboarding features, UX features, and adoption features. They make the first experience smoother for internal users and help keep the platform clean over time.

Before You Start: Practical Requirements

Before setting up SSO or SCIM in Pendo, confirm that your organization has the correct Pendo subscription capabilities. SAML SSO and SCIM provisioning may require specific plan access, enablement, or add-on support, depending on your contract. It is better to discover that during planning than during a live rollout while someone from IT is asking why the button is missing.

You will typically need:

• Organization admin access in Pendo.
• Administrative access to your identity provider.
• Permission to verify your company domain through DNS.
• A tested identity provider application for Pendo.
• Defined user groups for product managers, admins, analysts, customer success, UX teams, and other internal roles.
• A permission model that maps groups to Pendo roles.
• A rollback plan in case users cannot sign in after configuration.

That last point is not dramatic. It is just good manners toward your future self. Keep at least one administrative path available while testing, use a separate browser or incognito session to validate SSO, and avoid making sweeping access changes five minutes before an executive dashboard review. The universe has a sense of humor, but it is not always a friendly one.

How to Set Up SSO in Pendo

Pendo SSO is commonly configured using SAML, a standard that lets users sign in to Pendo through their company identity provider instead of managing separate Pendo passwords. The exact interface varies by IdP, but the general workflow is consistent.

Step 1: Verify Your Domain

Domain verification proves that your organization owns or controls the domain used for authentication. In Pendo, this is handled in Organization Settings, where you add your domain and follow the verification instructions. Typically, Pendo provides a DNS TXT record. Your DNS administrator adds that record to your domain, and Pendo checks whether it is present.

This step matters because SSO should never be enabled casually for a domain you do not control. Domain verification is the bouncer at the club door. It is not glamorous, but without it, things get weird quickly.

Step 2: Create or Configure the Pendo App in Your IdP

In your identity provider, create or locate the Pendo enterprise application. Many IdPs provide prebuilt SaaS app templates, which simplify setup by including standard fields such as entity ID, reply URL, assertion consumer service URL, and metadata options.

You will also need to decide which users or groups can access Pendo. For a clean rollout, avoid assigning “everyone” unless everyone truly needs access. Pendo is valuable, but that does not mean the entire company needs guide publishing permissions. Your finance intern probably does not need to edit onboarding modals. Probably.

Step 3: Add the SAML Configuration in Pendo

Once the domain is verified, go to Pendo Organization Settings and open the SSO tab. Add a new SAML configuration, select the verified domain, choose your identity provider, and provide the IdP metadata. When available, a metadata URL is usually easier to maintain than manually uploading XML, because it can reduce the pain of future certificate changes.

Pendo also allows configuration details such as signing authentication requests, depending on your business needs and security policy. Add a technical contact, preferably a team inbox or responsible identity owner, not a person who may someday leave the company and take the “SSO mysteries” with them.

Step 4: Save, Test, and Troubleshoot

After saving the SAML configuration, test sign-in from another browser or private browsing window. This prevents you from accidentally relying on an existing authenticated session. Confirm that users land in the expected Pendo organization and that role access behaves as expected.

If login fails, check the basics first: domain status, metadata accuracy, certificate validity, user assignment in the IdP, attribute mapping, and whether the user actually exists or is being provisioned. In SAML troubleshooting, the problem is often not mystical. It is usually a tiny mismatch wearing a trench coat.

How to Set Up SCIM in Pendo

SCIM provisioning helps automate user and group management between your identity provider and Pendo. Instead of manually inviting users, changing roles, or removing people one at a time, you can manage access through IdP groups and let provisioning do the repetitive work.

Step 1: Enable SCIM at the Organization Level

In Pendo, go to Settings, then Organization Settings, and open the SSO tab. In the SCIM settings area, enable SCIM provisioning. Pendo provides a base URL and API key that your identity provider uses to connect with Pendo.

Treat the API key carefully. It is not a cute little token to paste into random Slack threads. Store it securely, share it only with the identity administrator configuring the integration, and rotate it according to your security policy.

Step 2: Configure SCIM in the Identity Provider

In your IdP, open the Pendo application and configure provisioning. Paste the SCIM base URL and API key provided by Pendo. Depending on the provider, you may need to test the API connection, enable create/update/deactivate actions, and confirm attribute mappings for fields such as user name, email, first name, last name, and group membership.

For example, Microsoft Entra ID and Okta both support SaaS provisioning patterns where users and groups can be assigned to an application and synchronized through provisioning rules. The details differ, but the goal is the same: make the identity provider the source of truth.

Step 3: Prepare User Groups

Before pushing groups into Pendo, define them carefully. A clean group structure might include:

• Pendo Admins
• Pendo Product Managers
• Pendo Analysts
• Pendo Guide Creators
• Pendo Customer Success
• Pendo Read-Only Users

The exact naming convention is less important than clarity. A group called “Pendo-Prod-RW-2024-Final-v3” might technically work, but it will also make future admins stare into the middle distance. Use names that humans can understand.

Step 4: Push Groups to Pendo

After the SCIM connection is active, assign the Pendo app to relevant IdP groups and push those groups to Pendo. Pendo can then recognize the groups in its subscription access workflow. At this stage, verify that the intended users appear correctly and that group membership matches your access plan.

Step 5: Enable SCIM for Specific Subscriptions

Pendo supports subscription-level SCIM access controls. This matters for organizations with multiple Pendo subscriptions or multi-app environments. Enabling SCIM at the organization level does not automatically grant everyone access to every subscription. You must enable SCIM for the relevant subscription and assign permissions to the pushed IdP groups.

This is a critical step. When SCIM is enabled for a subscription, manual user controls may be disabled for that subscription, and access is governed through the IdP and Pendo SCIM settings. Users who were manually added but are not included in the mapped IdP groups may lose access. That is not a bug; it is the system doing exactly what you told it to do, which is sometimes the scariest kind of system behavior.

Step 6: Assign Roles and Permissions

Pendo roles and permissions determine what users can do. Admins may manage settings, integrations, metadata, users, guide themes, analytics structures, and other subscription-level controls. Other users may have more limited permissions for analytics, guide creation, tagging, or reporting.

Map permissions by job responsibility, not by job title alone. A senior product leader may need dashboard access but not guide publishing access. A lifecycle marketer may need guide creation permission but not integration settings. Good permission design should feel boring, predictable, and easy to audit. Boring is underrated. Boring keeps auditors calm.

SSO vs. SCIM: What Is the Difference?

SSO and SCIM are often discussed together, but they solve different problems. SSO handles authentication. It lets users sign in through a central identity provider. SCIM handles provisioning. It creates, updates, and removes user access based on identity data and group membership.

Think of SSO as the front door keycard. Think of SCIM as the office manager who decides which rooms the keycard opens and cancels it when someone leaves the company. You want both. A keycard without access governance is risky. Access governance without smooth login is annoying. Together, they make the experience secure and civilized.

Good UX Principles for Pendo Login Settings

Login settings are part of user experience, even though they live in admin screens. A confusing login process creates support tickets. A clean login process creates confidence. When configuring Pendo SSO and SCIM, apply UX thinking to the entire admin and user journey.

Make Access Predictable

Users should know how to access Pendo, which account to use, and who to contact if they cannot sign in. Create a simple internal access guide that explains whether users should go through the IdP dashboard, Pendo login page, or a bookmarked SSO link.

Use Clear Role Names

Group and role names should communicate purpose. If someone sees “Pendo Guide Publishers,” they understand the likely permission set. If they see “PX-Internal-Alpha-A3,” they understand that someone had coffee and no naming policy.

Design for First-Day Onboarding

New team members should receive access automatically when they join the right group. Their first experience with Pendo should not involve a scavenger hunt through IT tickets, old wiki pages, and one person named Brian who “used to handle that.” SCIM makes first-day access smoother when groups are connected to HR or directory workflows.

Design for Last-Day Offboarding

Good UX is not only about welcoming people. It is also about graceful exits. When someone leaves the company or changes roles, SCIM can help remove or adjust Pendo access automatically. That reduces risk and keeps your user list clean.

Provide Friendly Error Paths

If users cannot access Pendo, give them a clear next step. “Access denied” is technically accurate but emotionally unhelpful. A better internal support message might say: “You may not be assigned to a Pendo access group. Please contact the Product Operations team or submit an access request.” Tiny wording changes can save many confused pings.

Security and Governance Best Practices

SSO and SCIM are security controls, so treat them with care. Use multi-factor authentication through your IdP. Review group membership regularly. Keep a technical owner assigned. Monitor provisioning logs. Rotate credentials when needed. Test certificate renewals before they become emergencies. The best time to think about certificate expiration is not during a Monday morning outage while everyone is asking whether Pendo is down.

Use least privilege as your guiding principle. Give users the access they need, not the access that seems convenient today. Broad permissions feel fast in the beginning, but they create governance debt. Later, someone will ask, “Why do 86 people have admin access?” and the room will become very quiet.

Also document your configuration. Include your IdP owner, Pendo admin owner, group mapping, subscription mapping, role definitions, test users, and emergency rollback steps. Documentation is not glamorous, but neither is trying to reverse-engineer a login setup built by someone who left two years ago and named everything “test.”

Common Mistakes to Avoid

Turning on SCIM Without Reviewing Existing Manual Users

Before enabling subscription-level SCIM, export or review your current user list. Identify users who were manually added and make sure they are represented in the correct IdP groups. Otherwise, people may lose access when manual controls are replaced by group-based access.

Using One Giant Access Group

A single “Pendo Users” group may be fine for basic access, but it is usually not enough for mature governance. Separate groups by role and responsibility so permissions can be assigned with precision.

Forgetting Certificate and Metadata Maintenance

SAML depends on metadata and certificates. If those expire or drift out of sync, login can fail. Use metadata URLs when appropriate, monitor IdP alerts, and set reminders for certificate rotation.

Not Testing With Realistic Users

Test with more than one admin account. Validate access for an admin, a standard user, a guide creator, and a read-only user. A setup can look perfect from the admin chair while quietly confusing everyone else.

Ignoring the Human Side

Send a short announcement before changing login behavior. Tell users what is changing, when it is changing, how to sign in, and where to get help. The best authentication rollout is the one users barely notice.

Specific Example: A Clean Pendo SSO and SCIM Rollout

Imagine a SaaS company with 300 employees. The product team uses Pendo for analytics and in-app guides. Customer success uses dashboards to monitor account behavior. UX researchers use behavior data to identify friction. Leadership wants access to high-level reports but should not edit settings.

A practical setup might look like this:

• Pendo Admins: Product operations and platform owners with full subscription admin permissions.
• Pendo Guide Creators: Product marketing and onboarding specialists who can create and manage guides.
• Pendo Analysts: Product managers and UX researchers who need analytics access.
• Pendo CS Viewers: Customer success team members who need dashboards and account insights.
• Pendo Executives: Leadership users with read-only visibility into strategic reports.

With SSO, all these users authenticate through the company IdP. With SCIM, their group membership determines which Pendo subscription they can access and what they can do. When a customer success manager moves into product operations, changing their directory group updates their Pendo access. When an employee leaves, access is removed through the identity lifecycle. No spreadsheet. No “Can someone invite Maya?” thread. No archaeology.

How Better Login Settings Improve User Onboarding

Internal onboarding often fails because tools are technically available but practically annoying. New hires are told, “You’ll use Pendo,” but they cannot log in. Or they can log in, but they see the wrong subscription. Or they have access, but not enough permission to complete training. Every one of those moments creates friction.

With SSO and SCIM, onboarding becomes more systematic. When a user joins a department, the identity provider assigns them to the right group. Pendo receives the provisioning update. The user signs in with familiar credentials. Their role is already waiting. The product operations team can then focus on teaching them how to use Pendo well instead of manually unlocking the front door.

This also supports better UX education. Once access is reliable, teams can create role-specific onboarding paths. Product managers can learn funnels, paths, and retention analysis. Guide creators can learn targeting, segmentation, and guide governance. Customer success teams can learn account dashboards and product usage signals. Executives can learn how to interpret adoption trends without accidentally editing a feature tag. Everyone wins, especially the admin who no longer gets twelve access requests before lunch.

Extra Experience Notes: What Teams Learn After Living With Pendo SSO and SCIM

After working around Pendo login settings in real operating environments, one lesson becomes obvious: the technical setup is only half the project. The other half is organizational hygiene. A company can configure SSO perfectly and still create confusion if nobody knows who owns access, which groups map to which permissions, or how new users should request changes. The most successful teams treat SSO and SCIM as part of a broader product operations system, not a one-time admin chore.

A useful experience is to start with a small pilot group. Pick users from different roles: one admin, one product manager, one guide creator, one analyst, and one viewer. Have each person sign in, check their permissions, open the dashboards they need, and attempt common tasks. This quickly reveals mismatches between what the access model says on paper and what users actually need in the product. It is much better to discover that a guide creator cannot publish during a pilot than during a campaign launch with three stakeholders refreshing Slack like it owes them money.

Another practical lesson is that group naming becomes more important over time. At first, “Pendo Users” seems fine. Then the company adds multiple products, multiple workspaces, more departments, and a few compliance requirements. Suddenly that simple group is carrying too much responsibility. Teams that invest early in clean naming conventions usually have an easier time scaling. A good group name should answer three questions: which tool, which population, and which permission level. For example, “Pendo – Product Analytics – Viewers” is not poetic, but it is clear. In access management, clarity beats poetry almost every time.

Documentation also matters more than expected. A short internal page can prevent a surprising amount of confusion. Include the purpose of SSO, how SCIM provisioning works, which IdP groups control access, who approves new permissions, and what users should do if they cannot sign in. Keep screenshots updated when interfaces change. Add a small troubleshooting section for common errors, such as not being assigned to the Pendo app, using the wrong email domain, or missing the correct group membership.

From a UX perspective, the best login setup is nearly invisible. Users should not have to understand SAML assertions, SCIM endpoints, metadata URLs, or API keys. They should simply click, authenticate, and arrive in the right place. Admins, however, need visibility. They need logs, ownership, group mapping, and confidence that access reflects reality. This is the balance: invisible for end users, inspectable for administrators.

Finally, remember that Pendo itself is often used to improve onboarding and adoption for customers. Your internal Pendo access model should reflect the same philosophy. Reduce friction. Guide users clearly. Avoid unnecessary complexity. Measure what matters. Iterate when the first version is not perfect. In other words, treat your Pendo login experience like a product experience. Because it is one.

Conclusion

Pendo login settings may not be the most glamorous topic in product operations, but they are foundational. SSO helps users access Pendo securely through a trusted identity provider. SCIM helps automate provisioning, role assignment, group-based access, and deprovisioning. Together, they make Pendo easier to adopt, easier to govern, and easier to scale.

The key is to plan before clicking buttons. Verify your domain, configure SAML carefully, enable SCIM at the organization level, prepare clean IdP groups, map permissions thoughtfully, and test with realistic users. Then document the setup so future admins do not have to solve a mystery wearing a headset and a worried expression.

When done well, Pendo SSO and SCIM create a smoother internal onboarding experience, stronger security, and better operational UX. That means product teams can spend less time managing access and more time doing what Pendo was meant to help them do: understand users, improve adoption, and build better product experiences.

SEO Tags