OAuth 2.0 Client Integration Manager
The PTC Admin Center’s Integrations feature lets customer admins securely connect third-party apps, like ERP systems, to PTC Windchill using OAuth 2.0, enabling seamless data sharing and control over client access.
Role
Lead Designer, PTC Atlas Team
Key Collaborators
Product, Engineering, Design, Tech Writing
Project Timeframe
July 2023 - October 2023
Challenge
The PTC Windchill+ segment team, offering Product Lifecycle Management (PLM) software to customers, needed a way to connect Windchill data to their Enterprise Resource Planning (ERP) systems to better support critical downstream user workflows. Using the current applications within the PTC SaaS ecosystem, also called PTC Atlas, what new features would be necessary to bridge this gap for users?
Results
Windchill+ administrators can now use the PTC Admin Center to configure customer-led OAuth 2.0 integrations between Windchill and third-party ERP systems.
Key features include:
Secret key rotation
Callback URL editing
OAuth client field visibility and easy copying
These features manifest in the following two pages:
Integrations Overview Page - Final Design
Individual Overview Page - Final Design
Two Users, One Critical Gap
To get to the root of the integration challenge, I kicked things off with a series of deep dives alongside the Windchill and Atlas product teams. Through these early conversations, it became clear that two core user groups were affected and both had something critical to gain from a more connected ecosystem.
Windchill End Users
These are process engineers, QA teams, and service technicians who use Windchill to manage product data but rely on ERP systems to bring that data into the real world. From procurement to manufacturing, they need seamless access to Windchill data inside their ERP tools to drive critical workflows.
Windchill Product Administrators
Admins and technical support engineers use the PTC Admin Center to manage their organization’s SaaS tools. For them, enabling secure data flow between Windchill and third-party ERP platforms isn’t just helpful it’s essential.
What they both need
A secure, reliable way to connect Windchill data to external business systems - without workarounds or constant IT support.
With OAuth 2.0 selected as the authentication framework, I mapped user journeys, flagged edge cases, and refined requirements with stakeholders. These insights would shape everything that came next.
Seeing Through the Users’ Eyes
With the “why” understood, I turned my attention to the “how.” What exactly would these integrations look like in practice and what would users need at each step?
End User Scenario
Think process engineers using tools like PowerBI to visualize manufacturing data from Windchill. Their goal: bring live PLM data into external systems to uncover insights, streamline operations, and make data-driven decisions.
Organization Administrator Scenario
Organization administrators would use the PTC Admin Center in conjunction with the desired 3rd party ERP system to set up an integration. This part of my journey came with many questions, which I annotated and had to validate with stakeholders.
Learning the Landscape (and the Lingo)
With the user workflows mapped, I needed to better understand the technical mechanics, how OAuth 2.0 would actually work within PTC’s ecosystem, and what it would take to build a usable interface around it.
Many companies already offer similar solutions for configuring OAuth 2.0 clients/apps. Some examples include OpenAI (ChatGPT), Google, Microsoft, etc. During this research, I compiled a Miro board with product examples, taking note of patterns and behaviors.
Products I researched had similar features:
Ability to dynamically create OAuth 2.0 clients
Secret key rotation
However, while conducting this research, I realized that I did not fully understand the OAuth 2.0 protocol and how it fit together with PTC's application ecosystem. To fill this gap in knowledge, I watched Youtube videos and read documentation on the topic, and continued talking with the product and engineering teams to piece together any unknowns.
Creating an OAuth 2.0 diagram further helped solidify my knowledge of the topic and shift my approach towards also designing with technical constraints in mind.
OAuth 2.0 Technical Diagram
Evolving the Design through Iteration
Armed with a better understanding of the problem space, I moved into wireframing potential solutions. My initial designs were rooted in fulfilling basic requirements, but as I worked through iterations, they revealed new insights about the technical aspects of OAuth 2.0 integration.
In early discussions, we assumed the most critical part of the integration was the Secret Key, as it appeared to be the central connection between Windchill and third-party apps. However, as the team reviewed and tested my wireframes, we discovered that Client IDs played a more pivotal role in linking applications. This shift led to a redesign that moved from a Secret Key-driven interface to one that prioritized Client ID management.
Iteration 1: Laying the Foundations
This initial iteration aimed to fulfill the basic functional requirements, including:
Secret key rotation
Dynamic creation of OAuth 2.0 clients
Display of essential information like callback URLs
The layout was inspired by similar products I had researched, serving as a foundational step to help the team understand the critical components of integration.
Iteration 2: Refining Key Management
Building on the first iteration, I shifted focus to better organize the management of Secret Keys. I introduced a table layout to facilitate:
Key generation
Key rotation
Key deletion
While the static details (help text and Client ID strings) remained the same, this iteration better emphasized the management of Secret Keys, which was an essential step toward clearer usability.
Iteration 3: Shifting Focus to Auth0 Integration
In this iteration, the design evolved to focus not just on Secret Keys but also on managing Auth0 applications, the key mechanism for connecting customers with third-party apps.
Auth0 applications could range from native mobile apps to web applications, and the integration needed to handle fields like:
Secret keys
Callback URLs
We introduced default access to four Auth0 applications per organization, based on technical limitations at the time. Taking insights from the previous designs, I created a dedicated landing page for each application, improving navigation and usability for end users.
Honing in on the Final Designs
After validating my wireframes with key stakeholders, I moved on to high-fidelity mockups. Guided by insights from the wireframing phase and the technical structure of Auth0, the final designs coalesced into two core pages:
Integration Overview Page
Individual Integration Page
Page Anatomies
Integrations Overview
Navigation
A set number of integrations are provided for the Organization, based on customer requests. Each integration in the table provides navigation via its linked name and the Manage button to its individual configuration page.
Secret Key Rotation
Just like periodically changing passwords, regularly rotating the client secret that an app uses to authenticate is a security best practice. Whether a customer rotates it and updates their app with the new key based on security protocols or if they need to set up a brand new integration, this workflow allows for a one time visible key generation for all use cases.
Callback URL Editing
The callback URL typically specifies the URL of an app that is designated to receive an authorization code on behalf of the client app. In other words, the callback URL found within the 3rd party customer application must be entered into the Integrations page in order for PTC services to correctly redirect back to the client app after it requests data from PTC. This experience allows the Customer Administrator to update this field.
Looking back, thinking ahead
Reflecting on this project, there were several key learnings and future steps to come:
Learning #1 - Challenge Assumptions
The original assumption was that the most important part of integrations was the Secret Key, and that this was the main connecting piece to a customer's 3rd party application.
However, sharing rounds of iterations led us to understand that management of Client IDs actually serve as the links to client applications, which explains the shift in designs from a Secret key-driven UI to a Client ID-led UI.
Learning #2 - Collaboration
This project pushed me to navigate unexplored territories, specifically Auth0 and integrations, requiring close collaboration with developers and product managers.
Learning #3 - Trial and Error
Embracing a trial-and-error approach, we successfully integrated Auth0 into the user experience, revealing the intricate technical landscape. This hands-on experience highlighted the crucial link between design and development in overcoming complex challenges.
It not only solved immediate issues, but it also fostered a culture of continuous learning.
Overall Reflection
Looking towards the future, I'm eager to apply these insights, fostering a culture of adaptability and continuous learning to craft designs that seamlessly align with evolving technologies.
Design Next Steps
As other PTC products, beyond Windchill, progress in their transition to SaaS, this design will have to evolve to accommodate any additional steps and features required for integration. The roadmap for these products is currently in the planning stage, so stay tuned for updates!
