This experience is not available in the language you selected.
Proceed
Accelerate Windchill Navigate App Creation
Everything you need to implement Windchill Navigate for PLM data
Download Success PathIMPORTANT: When saving the file, in the Print window please do the following: Destination or Printer: select Save as PDF More Settings: In the Options, be sure the boxes Headers and footers and Background graphics are selected.
Accelerate Windchill Navigate App Creation
Everything you need to implement Windchill Navigate for PLM data
This is a PDF version of Accelerate Windchill Navigate App Creation. downloaded on Date : 12/24/2025 8:42:56 AM
and may be out of date. For full latest version click here.
Use this guide to plan, design, develop, and deploy Windchill Navigate for your organization. Provided are step-by-step instructions, training, documentation, and services to assist.
This information is useful for:
Project Managers
Organizational Change Management Teams
Adoption or Training Teams
System Administrators
IT Teams
Developers
UI/UX Designers
What is a Success Path?
A Success Path is an online guide to help you implement a specific PTC product at your organization. Each path provides step-by-step instructions from the early planning stages all the way through to deployment. Use a Success Path to help your organization get the most out of a product and achieve your business goals.
Windchill Navigate enables stakeholders throughout an organization to easily access rich data stored within the organization’s enterprise system, without the need for extra training. With out-of-the-box (OOTB) role-based tasks that provide contextualized information as well as the ability to easily tailor tasks to meet organizational needs, Windchill Navigate helps users spend less time searching for data and more time collaborating.
Windchill Navigate gives Extended Users, individuals who do not typically access PLM software, quick and easy access to Product Lifecycle Management (PLM) data such as drawings, documents, and designs, as well as change requests by simplifying and streamlining access to data. Users in manufacturing, procurement, service, sales and marketing, and quality engineering can view real-time, accurate PLM content via a simple, tailored interface.
There are two categories of Windchill Navigate apps:
View apps
Apps that allow users to view up-to-date product information (like parts lists or product drawings), but do not allow editing.
Contribute apps
Apps that allow users to add or change accessible data
The role of the user is tied to what apps are accessible. All data access is granted at the Windchill level, not the Windchill Navigate level.
Key functionalities of Windchill Navigate apps include:
Viewing and downloading PLM content like drawings, design files, part structures, and documents
Interacting with part models in 3D with cross selection capabilities using attributes
Reviewing, approving, commenting, and providing feedback on Changes
Building custom apps, using reusable components and mashup data from multiple systems; uses include supplier collaboration, production planning, and quality reporting
Flexible deployment options include on-premises or PTC SaaS. The application is web-based allowing for seamless install and upgrade.
02. Out-of-the-box and custom apps
Windchill Navigate offers a set of out-of-the-box (OOTB) apps as well as the option to build a custom app for a specific use case.
Each OOTB app is based on a user task to access PLM content for a job function or decision. An administrator configures and tailors the app for user roles without any development.
If an OOTB app does not meet your use case or requirements, you can build a custom app using the power of ThingWorx. For example, a custom app can source and compile data from systems other than Windchill. Custom app projects involve development and different licensing.
As you move forward, align your business use case to determine whether to use an OOTB app or build a custom app.
Windchill Navigate OOTB Apps
Functionalities
Search for and view a CAD document or part by name or number. All View Part apps allow the user to search.
All View Document apps allow the user to search for a document by name or number
View Design Files
Download a zip file containing all available design files
View Drawing
Launch a representation of the CAD document or parts drawing file
View and Measure in 3D
Launch the CAD document in Creo Lite utilizing WebGL
View measurements, angles, and comments within Creo Lite
Open the object’s representation in Creo View
View Part Properties
View additional attributes for a CAD document or part
View Part List
View the part list
Launch available drawing files for each part
Export the part list to a CSV file
View Part Structure
View the part structure table
View attributes or individual parts within a structure
Explore parts in a 3D environment
View Document
View document thumbnail and key attributes of the document
View and download document attachments
Launch the document in its original file format
View Document Structure
View document thumbnail and key attributes of the document
View the document structure table and additional attributes of the subcomponents in the table (for example, a section of a manual)
Launch the document in its original file format
Download Drawing Bundle
Specify a set of parts or CAD documents and download a zip file containing drawings for the CAD documents or parts in the set
Download individual drawing files for any of the parts or CAD documents
My Tasks (Change Management)
Review, approve, or reject change requests assigned via a task list
Access full details of Change Management Tasks including affected items and attachments
Check how others have responded, approved, rejected, or reassigned the tasks
Report a Problem
Report an issue about digital designs in Windchill directly inside of Windchill Navigate
Report from within a view task to associate the problem report to the affected object
Accessible for all user groups, not limited to subject matter experts
Enter text and upload images to describe the problem fully
Every year Windchill Navigate makes it easier to do your job and helps make you more productive. We recommend reviewing the features available with each version of Windchill Navigate.
Read technical details on Windchill Navigates' core features and functionality on the Help Center.
Use the Release Advisor to compare compatible versions of Windchill Navigate with other PTC products.
It is critical to choose the right use case for Windchill Navigate. Identify potential use cases to address problems and opportunities related to access to data. Consider whether use cases could be met by an out-of-the-box (OOTB) task or if you need to develop a custom app. Finally, prioritize your use cases and determine the scope of your project.
To understand how Windchill Navigate can benefit your organization, first get to know how people access product information today. Ask workers how they do their work. How do they currently get product data, drawings, or documents?
Get a sense of what is happening today. Look for insights to draw on later when it is time to develop use cases. Connect with people in roles like these:
Manufacturing: factory supervisor, factory worker, plant manager, production quality manager
Procurement: supply chain manager, partner manager, community manager, purchasing agent
Service: service technician, warranty claim manager
Sales and marketing: sales leader, marketing manager
Engineering: safety engineer, release manager, test engineer, requirements manager, system architect, quality manager
02. Understand Windchill pain points and needs
In addition to understanding current work processes, learn what challenges workers face when using Windchill that Windchill Navigate may help improve. For some organizations and users, Windchill can be a complex system. Using it may require in-depth training or frequent use in order to be beneficial. Take time to discover any pain points or difficulties your employees have when using Windchill.
Look for instances where:
Users spend extra time searching for information
Users are unable to find what they need
Users have created workarounds such as:
Asking engineers to spend time pulling reports
Using printouts and paper plots that go out of date
Making calls or sending emails that do not capture or control information
List pain points like frustration, wasted time, inaccurate information, or feeling a lack of control.
In addition to pain points, also document Windchill gaps. For example, where does a lack of real-time, accurate product information impact business results? Ask managers about related challenges and missed opportunities. A service manager may see a gap affecting their top goal of resolving more cases on the first call. A plant manager may talk about downtime.
As you have these conversations, document your findings. Do your best to avoid problem-solving and brainstorming. For now, get familiar with the challenges.
03. Identify potential use cases and estimate value
Review the processes, pain points, and gaps that you identified and consider potential use cases to solve these challenges.
Once you have a list of possible use cases, quantify their potential value. Get input from business managers. For example, if a plant manager estimates that online access to PLM content would reduce rework by 25%, what value might that deliver? If engineers spend 10% of their time pulling reports, what is the value of their time?
Estimate the value of each potential use case to get a sense of the benefit might be to the organization. The numbers may surprise you. Sometimes organizations have a particular use case in mind, but later discover that solving it will not bring as much value as another use case.
Consider whether you can accomplish any of your potential use cases with an OOTB app or if you should develop a custom app.
You can choose an OOTB app for a use case that extends access to PLM data through a user task supported by an available app. An administrator configures the OOTB app and tailors it for the user’s role. An OOTB app requires no development and can be deployed with less cost and time. View the available OOTB apps and functionalities.
If an OOTB app does not meet your use case or requirements, a custom app can be built using ThingWorx. A custom app may be necessary if:
There is no OOTB app for potential use cases.
You need to source and compile PLM content from Windchill and data from other enterprise systems.
You need to customize an OOTB app in any way to meet your requirements (excluding tailoring).
The expected business value justifies the investment of time and budget.
For your potential use cases, write down and compare high-level project costs. This will help you prioritize your use cases. Do not worry about detailed costs yet as those will be specified later.
As you estimate expenses, consider:
An OOTB app requires no development, fewer licenses, and less staff time.
A custom app often requires external design and development.
The number of new Windchill users for a use case affects license costs.
The number and location of new users will determine infrastructure needs and costs.
End-user training costs are minimal for OOTB apps. Custom apps may require training for developers and end users.
06. Prioritize use cases
Typically, the project sponsor works with leadership and group managers to prioritize use cases. It is important to involve end users so the chosen apps will meet their needs and expectations.
We suggest you create a matrix of each use case's.
Level of value
Solution type (OOTB or custom)
Level of cost
Time to value
Scalability
Fill in the matrix with the information gathered so far and new insights from leadership, managers, and end users.
Next, review the matrix for use cases that:
Are possible to address
Present high potential value
Can be attained with appropriate effort and cost
Together with leadership and managers, review the matrix, prioritize your list, and select your first use case. Do not be afraid to tackle big challenges with big returns. On the other hand, you may choose to start with a lower-cost project that fits the available budget and resources and will demonstrate value.
Document your decisions. Share the chosen use case with project stakeholders to get initial buy-in before assembling a team to develop a detailed project plan.
07. Identify project scope
Now that you have chosen a use case, define the scope of the project. A well-defined project scope will give stakeholders a shared understanding the objectives and size of the work. The project scope should include:
Number and roles of new users
Goals and metrics of success
Project phases and milestones
Deliverables and dates
Constraints
Acceptance criteria
Roles and responsibilities
How much time you expect employees to contribute
Other factors, depending on your organization and use case
For many organizations, the scope starts small. Over time, you may learn and iterate, extending the solution to solve other challenges. For now, ensure the scope is manageable for your use case.
Align on the project scope with leaders before forming the project team and developing the project plan.
Set Goals and Metrics
After you finalize your business use case, identify the specific goals you want to accomplish. Then determine which metrics will help you measure progress toward those goals. Share this information with stakeholders and the project team to build momentum.
Now that you know your selected business use case, identify goals that will help you achieve it. Clear goals help teams make decisions and keep the implementation on track. It will also set you up to be able to measure return on investment (ROI) later. Work with the same group of people who determined the business use case for Windchill Navigate.
Your goals should address the business challenges that you are using Windchill Navigate to solve. Each goal should be measurable.
Here are some examples of goals:
Increase the number of people who can access data by a specific amount
Decrease the amount of time engineering dedicates to answering calls by a specific percentage
Reduce product development costs by a specific amount
Reduce time to market by a specific amount
Next, determine what metrics, or key performance indicators (KPIs), you can use to measure progress toward your goals.
Some examples of metrics to measure progress are:
The number of users accessing information in Windchill Navigate
The number of new users from specific groups or work areas
The frequency with which users access data
The number of calls and/or meetings between groups
For a more specific example, imagine using the out-of-the-box app in Windchill Navigate called "My Tasks." It helps users track and review change requests assigned to them, including where a request is within a process and how others have responded. This provides data that you can measure, such as how long it takes for change requests to be approved, and what the trend is over time.
Whatever your goals and metrics are, check whether you can track the metrics that you listed. Talk with people in your organization who have access to data or collect data. That way you can set realistic expectations of what is possible. If you are not actively measuring these things, begin now.
02. Finalize goals and metrics
Collaborate with stakeholders and executive leadership to finalize your goals and metrics. Make sure the project sponsor, key leaders, and other team members agree on the goals.
Get agreement on:
What the goals are
What metrics will be tracked
When and how metrics will be tracked
Who the person/group is that is responsible for tracking metrics
03. Document baseline metrics
If possible, document your company's "as-is" state, or baseline metrics. This will help you prove ROI later. For example, if your goal is to reduce time to market, record the metrics of your current state of time to market before you implement Windchill Navigate.
In some cases, it may not be possible to get accurate baseline metrics. Maybe you are not able to measure the right things right now, but you will be able to after implementation. If exact metrics are not available or not accurate, estimate high-level baseline metrics.
04. Document plan to measure progress
After you identify your goals and metrics, document a plan for how you will measure progress and success.
In your plan, outline the following:
Goals
Metrics
Roles and responsibilities
Who will track and report performance?
Who needs to be informed?
Key milestones
Baseline metrics (current state)
Share your plan to measure progress with stakeholders. Refer to it throughout the project to make sure you are on track.
Build Project Team
To achieve your Windchill Navigate use case, build a team with both Windchill and ThingWorx experience. Explore the skills needed, and find them within your organization or through outside resources.
A typical project team includes the following roles. Titles may differ, and one person may play more than one role. A custom app might require other skills not mentioned here.
Project Sponsor: The project sponsor, a senior manager, leads the process to get approval of the project, scope, and budget. The sponsor is the project champion and is accountable for its success.
Skill sets needed:
Leadership
Cross-functional collaboration
Gaining project buy-in
Able to assess business use cases
Able to determine business value
Project Manager: This role facilitates the planning and execution of the project to keep it on track. The project manager tends to be more involved in custom builds to monitor progress and manage dependencies, risks, and budget.
Skill set needed:
Common project manager skills: scheduling, tracking progress and costs
Meeting management
Communication and reporting skills
Familiar with Windchill
Administrator: The Windchill administrator usually fills this role. PTC’s product documentation assumes the administrator has done a Windchill implementation. Some organizations add a dedicated Windchill Navigate administrator as they scale and expand usability.
Skill sets needed:
Knowledge of Windchill functionalities and features
Knowledge of Windchill users and processes
Knowledge of Windchill data schema
License management
For out-of-the-box (OOTB) apps: Windchill Navigate installation, configuration, tailoring (admin training is available)
IT Administrator: This role is responsible for infrastructure, network security, and authentication. If you implement single sign-on (SSO), your project will be smoother if the IT partner has done it before.
Skill sets needed:
Familiar with infrastructure costs and procurement
Hardware implementation and configuration
Understands data architecture including Windchill
System integration
Understands security requirements including certificates and current Windchill security
SSO configuration
Developers: You will need developer skills only if you are building a custom app. A custom app requires ThingWorx developer skills and Windchill knowledge. System integrators can help fill some gaps.
Skill sets needed:
Experience gathering use requirements for the UX designer role
Familiar with UI/UX design principles
Familiar with ThingWorx app design and development (training is available)
Familiar with Windchill Navigate app development (training is available)
Understand ThingWorx platform
Understand Windchill functionalities
Understand Javascript
Understand REST API
Experience with testing and validation
UX/UI Designer: If you are designing a custom app, a UX/UI designer will improve the look and feel of the application interface and make it easier to use.
Skill sets needed:
Proficient in CSS, Adobe Photoshop, Adobe Illustrator, and/or Sketch
Familiar with user-centered design principles
Experience designing mobile, tablet, and desktop applications
Organizational Change Manager: Organizational change management is a critical but often overlooked role on Windchill Navigate teams. This work may be shared among several individuals or a team.
Skill sets needed:
Change management
Process change
Training
Communications
Business Process Consultant: Although not critical, a business process consultant will help determine how to best intersect new technology with your business processes to improve efficiency and achieve your use case.
Skill sets needed:
Thorough understanding of your organization and specific business processes as they exist today
Experience with process modeling and the creation of future processes
Experience partnering with stakeholders to gather business requirements
02. Identify project stakeholders
Stakeholder support will be a key asset throughout your initiative. Cultivate buy-in at various levels of your organization, from high-level business leaders to frontline workers. These are our stakeholder suggestions, but you may have others depending on your use case and the structure of your organization.
Corporate Executives: Your most important stakeholder will be at the executive level. Identify a well-respected, well-connected executive who will advocate for your initiative on an ongoing basis. Engage executives in parts of the organization your use case will benefit, for example manufacturing or procurement.
End Users: Windchill Navigate will put PLM information in the hands of people who don’t use Windchill currently, typically because of its complexity. Identify the existing and new Windchill users. New end users may be in manufacturing, purchasing, marketing, sales, supply chain, customer support, or other groups. Additional product designers and engineers may also use the app.
To ensure the app gets used and delivers value, involve representatives of major end user groups throughout the project. Their insights will improve experience design, documentation, training, and change management. Also, talk with those who currently spend a lot of time pulling reports for others, such as engineers.
If you are developing a custom app, you will need end users to test the app in the real world. Identify a group of workers who can test and provide feedback on early-stage app designs. These workers should represent your ideal end users. They will help you identify urgent fixes and opportunities for improvement before you implement Windchill Navigate on a larger scale.
Long-term Support Team: Identify the IT support staff who will manage and support the app after it goes live. This team will fix bugs, do upgrades, and provide users with tech support. The long-term support team is important to the success of the software and your return on investment. Involve them early and plan for training, documentation, and a smooth handoff.
03. Request time for the team and fill skill gaps
Find out whether your organization employs people who have the skill sets you need. If so, ask whether they can contribute to the project. Get manager approval if needed. Usually, the project sponsor assembles the team, working with the project manager if one has been identified at this point.
The project team can do most work remotely. If possible, members should be on site to gather requirements and at go live.
Organizations that build a custom Windchill Navigate app often hire contractors or consultants to bridge skill gaps and achieve their use case. Verify that outside resources you hire have the right skills and experience to meet your project goals.
If you purchased a Success Plan from PTC, talk with your Customer Success Manager to ensure you have the right mix of resources on your team. If you do not have a Success Plan, contact your sales representative.
Schedule a team kickoff meeting led by the project manager to introduce the project, roles, and next steps.
The team will first finish planning the project and get it approved. IT will work on compliance and security. Others will identify costs and determine licensing needs. The project manager will facilitate team meetings, set up the timeline, and create a communications plan for project stakeholders.
Define Compliance and Security Requirements
Utilize the information below to prepare to install Windchill Navigate on-premises before beginning the installation. Once complete, follow the instructions to download, install, and configure your software. Work with the PTC Cloud team if Windchill Navigate will be deployed on the PTC-hosted cloud.
Depending on industry, compliance and regulatory guidelines may impact the project. These may include:
Restrictions on what you are able to do
Mandates on things you have to do
Windchill Navigate can help any organization with compliance. As an example, Windchill Navigate provides the ability to require an e-signature on any Change Management Task.
Meet with regulatory or quality assurance teams to understand restrictions or mandates specific to your industry. Document and share those requirements with the team who will be implementing Windchill Navigate.
02. Determine authentication and security requirements
Consider which internal personnel should have administrative rights. These individuals will have more capabilities than other users and as an administrator can configure all tasks to retrieve and show exactly the information that users in your organization need. Tasks can be tailored individually or collectively.
Windchill Navigate uses Windchill’s existing security capabilities to control access to data. Decide how users will authenticate by discussing authentication with admins, IT leads, project sponsors, and stakeholders involved in security. Depending on your current IT practices, the size of the company, and other security needs, you might choose:
Single sign-on (SSO)
PTC recommends Single Sign-on authentication. Users will utilize a single login to access multiple enterprise applications. PTC supports industry SSO standards and has incorporated PingFederate as an SSO solution.
Windchill Authentication
This option uses Windchill authentication for ThingWorx. A user that opens a browser to a mashup or any ThingWorx URL is routed to Windchill for authentication. Once authenticated, the browser is routed back to the mashup or another page in ThingWorx and the user is able to access ThingWorx or the mashup as the user authenticated in Windchill.
Fixed Authentication (Service Account)
If there is a need for a quick setup for testing, or to demonstrate Windchill Navigate functionality, fixed authentication is a viable solution. Fixed Authentication is not secure and should never be used in production.
The decision regarding authentication will affect project costs, timeline, and skills needed. SSO is the recommended authentication method, however, does require knowledge of Identity and access management standards.
If any system outside of Windchill, ThingWorx, and Windchill Navigate will be required, plan accordingly by considering a custom option. ThingWorx has been built to follow the guidelines and guardrails compatible with Windchill+, increasing security and reducing customization costs.
Behind every successful project is a thorough project plan. The project manager leads the development of the timeline, licensing plan, cost considerations, and stakeholder communication plan.
Create a project timeline that includes completion dates, phases, milestones, and dependencies. As you build out the timeline, ask your project team for input. For example, if you plan to use single sign-on for authentication, ask IT for an estimate on how much time they will need to configure it.
Generally, implementing an out-of-the-box (OOTB) app takes about four weeks from start to first use. The project may take longer depending on the availability and experience of your project team, among other factors.
If you are developing a custom app, your timeline will be much longer and will depend on many factors including your app design, data integrations, potential infrastructure changes, testing, and overall availability of skills and staffing.
In your timeline, include change management tasks such as training and communications. Start the adoption team’s work early enough so training materials, documentation, and communications will be ready for go-live.
Your timeline should be created by your project manager and then approved by your project sponsor. Moving forward, the project manager monitors progress, budget, dependencies, and upcoming milestones. They will also communicate progress with project stakeholders throughout the project.
02. Evaluate licensing
You will need the right type and number of licenses in time to install the app and start configuration and development. Start evaluating licensing needs as soon as you know the use case and the expected number of daily users.
Have your site administrator review the licenses your organization has today. Request a Detailed License Report for each installation site. Then contact your PTC sales representative to find out what licenses you need based on your use case for Windchill Navigate.
Most Windchill Navigate licenses, including those for OOTB apps, are for active daily users (as opposed to named or dedicated licenses). A group of users shares licenses over a 24-hour calendar day up to the limit of the number of purchased licenses.
An OOTB license comes with all available apps that can be implemented. The license packages are:
The cost of your project depends on the use case, scope, and internal resources. If your use case benefits multiple groups, determine who will share costs, for example development of a custom app.
Identify costs and document estimates as best you can. Consider the following:
Users: Determine the number and location of users as early as possible. This will help you determine costs and needs for infrastructure and licensing. Servers should be located near the users to reduce data-transfer time and avoid government restrictions on receiving or sending data with other countries. Ask the managers included in your use case for numbers and location of users. You do not need individual names of users until you assign people to user groups.
Internal time: Estimate the number of hours team members will spend on the project and communicate the needs to their managers for resource planning and budgeting. Include time for meetings, training, testing, and supporting the app. For a custom app, include time for early users to give design feedback and test the app.
External resources: Consider whether you will hire contractors or services to implement the software.
Infrastructure: Consider how you will deploy your app, whether on premises or the cloud, and the servers you will need. Your IT group will determine infrastructure needs. Windchill Navigate must be set up on a dedicated server if you are deploying on premises.
Software: Consider possible licensing costs to acquire or update software. The Windchill Navigate Compatibility Matrix provides detailed information about supported platforms, including Windchill versions and patches.
PTC support package: Consider purchasing a support package if you do not have one so you can benefit from PTC’s technical support and resources.
Gather estimates of costs in order to get approval for the budget. You will add up detailed costs later.
Document the project plan including team members and roles, timeline, licensing plan, and identified costs. Ask your project sponsor for review and approval. You may need other approvals depending on your organization’s processes.
05. Plan communications to project team and stakeholders
As you move forward with your project, communicate progress with internal stakeholders often. They include the project team, project sponsor, executives, and managers in the group that will use the app. Document a simple communications plan so you make sure to get the right audiences the information they need and want. Without a plan, communication may not happen, which can affect executive buy-in and user adoption.
Include in your communication plan:
Your audiences, the stakeholders or groups you need to communicate with during the project
What information is most important to which audience so that you can avoid communication overload
What you need from stakeholders at various points along the timeline
Best communication channel for each audience whether it is email, meetings, or something else
How project team members will communicate with one another, including channels and regular check-ins
How stakeholders can send feedback and needs
The project manager should create this plan with input from others. Be sure to let stakeholders know how they can reach you and the best ways to provide feedback. Later, as part of organizational change management, you will create a plan to communicate with the new users and the rest of your organization.
Design the App
Learn to design and develop in ThingWorx. Gather requirements to inform the design of your custom app. Then sketch the first draft to test the design with users.
If you are implementing out-of-the-box apps, skip these tasks. You'll tailor the apps to user needs later.
To build a custom app for Windchill Navigate, take the time to learn to design for and develop in ThingWorx. This will help you gather essential requirements. It will also help you learn what is possible in ThingWorx. The recommended method for development for Windchill Navigate is via Building Blocks. Building blocks are modular components used to create independent, reusable features for IoT solutions. Each building block serves a specific function, such as data integration or user interface, and can be combined with others to build larger applications.
User experience (UX) principles
User interface (UI) design
ThingWorx development, including using ThingWorx Composer to create Mashups
One person may have these skills, or they could be shared among several. If your company does not have these skills readily available, work with PTC or an experienced partner. PTC offers services and training courses to help. For example, the service "Execute Windchill Navigate Design Workshop" (listed in the services below) will help you determine how your app should look and operate based on your UX requirements.
Training courses are available from PTC University. Some may have prerequisites. To determine which courses best meet your needs, speak with a Training Advisor.
Individuals with limited or no ThingWorx experience will benefit from this course. Learn about the ThingWorx development process including how to use ThingWorx Composer and Mashup Builder.
User experience (UX) requirements help you understand how users will interact with your app, what the app looks like, and how the user interface (UI) works. We recommend that an IT lead and UX/UI designer work together to gather requirements. If you do not have access to these skill sets, PTC offers the "Execute Windchill Navigate Design Workshop" linked in the services below.
To gather UX requirements, start by interviewing your users. Users are the people who will use the data from the app. Explain the business use case and ask them what data is most important to help them meet that goal. Ask users how they will search for information in the app. It may be helpful to ask them to demonstrate their current workflow.
As you gather UX requirements, your research should answer the following:
Who will use the app?
What languages do users speak?
What will they use the app for?
What devices will they use?
Are there existing styles or colors to adhere to?
What data is most important? How often does it need to refresh?
What systems or devices need to connect or where is data coming from?
What actions do users need to be able to take?
How will users go looking for information? For example, will they type in a search field, use a drill down menu, navigate a tree-type hierarchy, etc.?
Do users need to generate any reports?
Will the app have alerts? If so, how will users interact with alerts?
What levels of visibility and permissions will different users need?
What other security requirements will affect the user experience or the UI?
As you research, document your findings to form UX requirements. You will refer to your requirements as you create and iterate on the UI.
03. Write user stories
Write user stories before you create an initial design. For this purpose, a user story describes what a user’s goal is in the app based on their role or job.
You will need the user stories to design the flow of the app. They will help you determine whether the design meets user needs and will be useful when you test your design. Write stories for the various jobs identified in your UX requirements so that your app is inclusive of many needs.
Format user stories like this:
As a [person in a role], I want to [take an action or find something out] so that [desired outcome].
Example:
As a manager, I want to find production data from the last fiscal year so that I can find out if we are on track this year.
User stories should align with your use case and be real-world scenarios. Document the user stories and include them in your UX requirements.
04. Create UI designs
Next, create your initial designs. Review your UX requirements and the business use case to lay out a sitemap or navigation for the app. A sitemap is a diagram that shows the organization of the app and what is included. It helps you establish a hierarchy of elements and get an understanding of your ideal user flow. Use the sitemap to show how things are organized and labeled.
Once you have created a sitemap, design wireframes. These are your first drafts of the user interface (UI) of the app. A wireframe is a low-fidelity, early-stage design. It often contains a grid of empty boxes that represent elements on a screen. To make a wireframe, you can use a tool like Balsamiq or Axure or draw it by hand.
Wireframes provide direction to the developers who will build the app. They also show how users interact with the app. You will be able to use wireframes to test the design with users later.
Focus on what is most important for functionality. The goal of the UI is to make it easy for users to get the information they need when they need it. Look back on UX requirements, user stories, and the business use case. Instead of filling up the screen with widgets, we recommend that you leave blank space. The fewer elements users see, the easier the app will be for them to learn and use. Focus on the user flow and user interactions with the elements. Do not spend time on colors, images, or other styling choices yet. You will make those decisions later.
In your wireframe, include the following:
Elements on the screen
Use boxes to represent the navigation, titles and labels, blocks of text, tables, graphs, images, buttons, etc.
Priority and relationships
Arrange and connect elements to reveal which items are most important.
Interactions
For interactive elements, note how elements respond when a user clicks or taps on it.
Flow
Outline which screen leads to the next if there is more than one.
Show whether the application delivers alerts.
Preliminary copy
Include words in your design that convey what each element is and does. For example, a heading may say "battery life" or a button may read "view all machines." You can update words throughout the design process.
As you design, you will create a sitemap and wireframes. You should also end up with a design document that outlines your design. Keep the design document up to date as you go through design iterations and development.
05. Review and iterate designs with users
Once you have wireframes that meet the business use case, you are ready to test them. Go through your user stories first. How do the wireframes perform against the user stories? Make any changes to your wireframes to solve issues that you notice.
Then test the wireframes with real users. Choose a small group of key users to review your wireframes. The key users should have a stake in the success of the app and are part of the main audience for the use case. Get their feedback and evaluate whether the UI is easy to follow.
What you are looking for:
The UI includes every element it needs to
The UI is intuitive, easy to understand, actions are easy to take
The UI looks and feels the way users want it to
The app does what is expected
The user flow meets the business use case
The UI leads users to their desired outcome (that meets the business use case)
If you need to make changes to the UI, update the wireframes and test with users again. This is a fluid, iterative process. You should feel comfortable making rapid changes and responding to feedback.
You can consider your UI design ready for development when you have met your UX requirements, it aligns with your business use case, and users verify that it meets their needs. Update your design document with any changes so that it is prepared for the developers to use later.
Plan Integrations
After you identify the data that users need to access in Windchill Navigate, understand where that data lives and why you need it. Then determine the best way to integrate systems to retrieve the data.
If you are implementing out-of-the-box apps, you do not need to gather data requirements. The app is already designed to access the data required from Windchill.
To plan integrations for a custom app, gather data requirements first. Use your design document and wireframes to understand information you need.
Document the following:
The data you need
Note the specific pieces of data or metrics you need to build the app for your use case.
Where that data currently lives (Windchill, a third-party system, a .csv file, etc.)
Who currently has access to that data
How often data needs to be updated
How frequently should the data refresh in order to be useful? Keep in mind that the higher the refresh frequency, the more transactions your infrastructure will need to support.
What format the data should take (a number, integer, string, Boolean, etc.)
How the data should be displayed to the user (a table, chart, etc.)
Does the data need to be transformed or aggregated to be useful?
Whether the connection needs to be unidirectional or bidirectional
Does ThingWorx need to be able to pass information back?
If so, what happens once data is passed back?
Why you need the data
It can be tempting to ask for every data point available, but that often leads to an overload of data. For each piece of data you are requesting, make sure you know exactly why you need it to accomplish your use case.
Categorize each piece of data to help understand if you need it.
Actionable data typically triggers some sort of action or response. This data tends to be acquired and published near real time.
Informational data represents various properties of your products or assets and typically changes infrequently.
Historical data is used to represent rends or maintain a short-term record of information and events.
Cold storage data is often used for data mining and analytics purposes and does not need to be accessed or seen often.
Understand what data you need and why you need it to help you have more effective conversations as you determine how you will retrieve data. Be prepared to rework requirements as you decide what is most important and what is possible.
02. Determine how systems will connect
How you connect your systems will depend on your use case, data requirements, existing systems and protocols, security, infrastructure, and network. For example, you may be able to use Windchill REST Services or you may need to build custom connections.
Windchill Navigate offers a way to view and configure data from multiple systems. ThingWorx connects Windchill and other third-party systems with Windchill Navigate to combine and view data seamlessly, configure dataflows, and create custom Navigate apps without creating duplicate information. See Install and Configure ThingWorx in the Help Center. Once installed, you can combine ThingWorx connectors for Windchill to third-party systems using Navigate UI components to speed up app development.
To decide on the best approach, have detailed conversations with those who have a deep understanding of the specific data and systems you need to connect to. This might include IT partners, system admins, or developers. If possible, involve someone with extensive ThingWorx knowledge and someone familiar with your Windchill instance.
As you work through this decision, document which data sources you need to connect to and how you plan to connect to them. Compile and share this with the project team. How you integrate systems will impact the skill sets you need, timeline, costs, and possibly your infrastructure.
Depending on the system you are connecting with, the following resources can help:
Before you install Windchill Navigate, learn about user groups. Then, decide what user groups you need for your app. Your approach will differ depending on whether you are using out-of-the-box (OOTB) apps or building a custom app.
In Windchill Navigate, user groups determine visibility (what users can see) and permissions (what users can do). They are based on roles and the tasks users need to do in the app. Likewise, user groups limit what users can see and do.
Depending on whether you are using out-of-the-box (OOTB) apps or building a custom app, the way you define and create user groups will differ.
User groups for OOTB apps
OOTB apps have predetermined user groups that are connected to licenses. Users will either:
Have their own named license as part of a specific user group, or
Be part of a group in which they will check out a license when they need to use the app.
After you install the software, you will assign each user to one license group based on what they need to do in the app. To learn about the licensing groups for OOTB apps, review Modify ThingWorx Permissions: Users and Groups.
User groups in ThingWorx for a custom app
If you are building a custom app, you will define and create your own user groups. ThingWorx also offers built-in user groups for administrators, developers, and users you could use to start.
When you are ready to create groups, you will make groupings at three levels in ThingWorx Composer:
Organization
Organization unit
User group
Different user roles direct what different types of permissions you need to give to a user group. A user role is a person or group who can take specific actions in the app using specific data. For instance, a user role might be a support engineer (user role) who pulls reports (permission) for a site in Europe (visibility). Anticipate that your user groups and organization units may expand over time.
In ThingWorx, there are three forms of permissions you can adjust:
Visibility permissions state what Mashups and/or dashboards a user can see. Assign visibility permissions at an organization or organizational unit level.
Run-time permissions state what services a user can execute and what properties they can access. Assign run-time permissions at the user group level.
Design-time permissions state what a user can modify and access in ThingWorx Composer. Assign design-time permissions at the user group level.
Your developer or development team should become familiar with ThingWorx Composer in order to create user groups. PTC has training courses available to help, such as ThingWorx: Fundamentals of Deployment.
Based on your selected use case, determine what user groups you need and who will be part of each group. Include all types of users across your organization, from admins to end users.
The project sponsor, admin, developer, and key stakeholders who are familiar with the data should collaborate to define and list user groups. Understand what your app does and what people will use it for.
Define user groups for OOTB apps
To define user groups for OOTB apps, determine:
Which users need a permanent license
Which users will check out a license instead of having a permanent license
Which app(s) each type of user needs access to
Document who will be part of each user group so that your implementation team is prepared to add users after installation. This document will help you troubleshoot and manage user groups later.
Define user groups for a custom app
To determine user groups for a custom app, first document requirements for visibility (what users can see) and permission (what users can do) for each type of user. Then group users together based on similar requirements. Consider whether the built-in user groups for administrators, developers, and users may be enough to start with.
Requirements should align with your selected use case. Be as accurate as you can in your documentation. If users have too much access, they could see confidential data they should not have. If users have too little access, they may not be able to see the data they need.
Document the user groups including visibility and permissions so that your developer and admin know what user groups to create. This document will help you troubleshoot and manage user groups later.
Finalize App Design
Create a technical design document to guide the implementation of Windchill Navigate. Review the design with the project team and make sure it aligns with your use case.
Create a technical design document to prepare the team for installation and configuration. This comprehensive document will provide direction for the person or group who installs, configures, and writes code for the app. The senior developer or someone with the skills of a solution architect should create the document.
Review and include some of the key decisions you’ve made so far.
The systems you’re going to integrate with and how you’ll make those connections
Compliance and security requirements, including authentication
Mashups and/or Thing models that apply
Deployment approach (on-premises or cloud)
Not all of these items may apply, depending on whether you’re implementing out-of-the-box apps only or developing a custom app. Adapt your technical design document to your team's specific needs.
Review the technical design document with your project team and stakeholders. Discuss all the details so that project team members understand the various elements of the design and how each component works together.
Verify that the design satisfies the user requirements and aligns with your use case. Take time to answer questions and address concerns before you install the software or begin development.
Before you write any code for a custom app, determine your development processes, specifically source control. Source control refers to how you will track and manage versions of code. A method for source control will speed up deployment, minimize mistakes, and help you resolve conflicts in the code. Your company may already have defined DevOps tools and processes. If not, you will need to define your own. There are tools available to help.
For code management, you can use widely available tools like Git or Subversion (SVN). You can export and deploy code that you develop in Windchill Navigate using standard ThingWorx Export/Import functionality. For Windchill REST Services, manage the extensions similar to how you manage regular Windchill customizations. You can deploy them using build automation tools like Ant, Maven or Gradle.
We recommend that the developers only write code in the dev environments (not QA, test, staging, or prod) for Windchill Navigate and Windchill instances. For example, if you need to customize Windchill REST Services, only write code in the separate Windchill dev environment. This will prevent confusion and inaccurate test results later.
As you decide how to best track and manage code, consider the following:
What development environments you need for each system (Windchill Navigate, Windchill, external system, etc.) and what you willvdo in each. We recommend at least 4 environments per system:
Dev: create new apps, features, or work on patches
Test/QA: validate and test new versions, patches, and configurations
Staging: a close replica to your prod environment to do integrated, end-to-end tests such as for scale and load
Prod: host the live, tested applications that users will interact with
ThingWorx naming conventions
For Windchill REST Services, follow the same naming conventions as regular Windchill customization
Security requirements including authentication and user groups for both Windchill Navigate and Windchill
You will need a testing plan whether you implement out-of-the-box (OOTB) apps or create a custom app. The project manager, developers, admin, IT, and key power users who will be involved in user acceptance testing should work together on a testing plan. Decide what tests to run based on your requirements, app user interface (UI), and technical design document.
In general, we recommend the following:
Unit testing: test each service (ThingWorx and Windchill REST Service) with different parameters to assess whether code behaves properly within, without, and at the defined limits
Integration testing: after unit testing but before system testing, test that all components integrate well with one another
System or functional testing: test the features and functionality of a collection of components defined by the use case
Security and penetration testing: test for vulnerabilities, risks, and threats
Stress or load testing: test the stability of the app and how it handles errors and load
User acceptance testing (UAT): test with select end users to make sure the app meets their needs
Deployment testing: test that the installation works as expected on a staging server that represents a production configuration
Document a testing plan including what tests you will do in each environment. Remember to consider security and compliance requirements at every stage.
Make one overall testing plan that includes:
Summary of what the app does (refer back to your use case)
Data sources and data flow
Design specification/technical design
Acceptance criteria
Test procedure
Test cases
Environments and who has access to what
Security requirements
ThingWorx version or release numbers
Results of quality assurance (QA) test
Performance figures
Revisions
Software
You may not have some of this information until you start testing. Some items may not apply if you are implementing out-of-the-box (OOTB) apps.
03. Write test cases
If you are creating a custom app, write test cases so that you can test the app once it is developed. Your company may already have a process to write test cases. But if not, we recommend the project manager, project sponsor, and key stakeholders write these together.
When you write test cases, make sure they align with your selected use case. The goals and metrics that you wrote might also provide requirements that your app needs to meet. Write to real-world scenarios that people in your company will experience within the use case.
Consider test cases for different types of users as well as different types of data the app makes available. To be effective, tests should replicate what it is like in the real world. Plan to complete these tests in a QA or staging environment that replicates your production environment as closely as possible.
Document your test cases and include them as part of your overall testing plan.
Plan Infrastructure
Depending on how you deploy Windchill Navigate, you may need to make changes to your infrastructure. Evaluate your current infrastructure and decide how to move forward.
Before you deploy Windchill Navigate, evaluate your current infrastructure to find out what changes you need to make. Consider impacts on other systems, such as how more users will affect the load on those systems. Involve the project members who will configure the infrastructure and those who designed the app who know what systems and data you need to connect with.
Will you deploy Windchill Navigate on-premises, via PTC-hosted cloud, or private cloud?
Availability
Will the app always need to be available? Is downtime acceptable? Consider both planned downtime (upgrades, updates, maintenance) and unplanned (failures, outages).
Development environments for each system involved
How many development environments will developers need for each system (Windchill Navigate, Windchill, etc.)? How many users will each environment need to support? Developers use different environments for different purposes. Refer to your source control and testing plan to see what they require. We recommend at least four environments:
Dev: create new apps, features, or work on patches
Test/QA: validate and test new versions, patches, and configurations
Staging: a close replica of your prod environment to do integrated, end-to-end tests such as for scale and load
Prod: host the live, tested applications that users will interact with
How will security requirements affect your infrastructure? How might security change over time?
What changes will need to be made if you’re using single sign-on (SSO) for authentication?
Usage
How will increased usage affect each system involved (Windchill Navigate, Windchill, etc.)?
What hardware will you need for each system involved?
How much processing power and memory will the hardware require? Consider:
The number of users during peak usage
The number of data points called during peak usage
The complexity of the business logic and Mashups being used
Networking to support users
Do you have the network to support the users of your app?
What devices will your users be using?
Will end user devices impact the network design?
If you need additional help determining server sizing, PTC offers the service “Evaluate Your ThingWorx Server Sizing Requirements,” linked in the services below.
Take note of what you’ll need to purchase and document any changes to your infrastructure. Your IT group will need to prepare to make these changes.
Make sure the project manager and sponsor understand how infrastructure changes will affect the project planning including costs, timeline, and skills needed to complete the work. You might consider how to adjust your app design to work within the constraints of existing architecture until you’re able to upgrade.
03. Buy additional hardware
If you need additional hardware, buy it as soon as possible. This is especially important if the procurement process at your organization requires multiple approvals or takes a long time.
Plan Organizational Change Management
Plan communications, documentation, end user training, and how you will support the app long-term. For your app to deliver expected value, users need to understand and embrace changes in technology and processes.
Start by finding out what will change when users access product information with the new app. Gather insights into the users, the process that will change, and ways the app will help them. This work should be completed by your adoption team, or the person or group responsible for organizational change management.
Learn about the app and the reason for your selected use case. If needed, follow up with the project sponsor about the challenges and value that pointed to this use case. Review any notes from the research into potential use cases. For a custom app, talk to the design team about the functionalities and use.
You can also gain important insights by talking with some mid-level and frontline staff who will use the app. They understand the current process and problems and can anticipate problems and resistance with the introduction of the new app. They can also help you be sensitive to cultural norms at their location around communication, hierarchy, and change.
After people adopt the app, they should find it simpler and faster to access product information. However, when they first hear a new app is coming, they may anticipate it will be complex or disruptive, especially if they have struggled with Windchill in the past. Even if they do not like the current processes, they are likely comfortable with them. A simple change can feel disruptive at first.
To help employees embrace change:
Communicate consistently
Listen openly to concerns and questions
Encourage participation
Share the benefits to your organization and its employees
Get leadership to sponsor and promote the initiative openly
Develop a change management plan
Dedicate resources to put change management into practice
02. Create a communication plan
Plan how you will communicate during the project with various audiences that are external to the project team.
Your most important audience is the end users. They need to know the app is coming, when it is coming, why it is important, what it changes, and how they will learn to use it.
Group managers will need to know what is coming as early as possible, so they can manage change within their teams. Ask them if they work with other groups that will be impacted and will need some level of communication.
Plan how you will communicate with executives and the broader organization. This could be an opportunity to create interest in other use cases for Windchill Navigate.
Use these questions to guide your communication plan.
Who are your audiences outside of the project team?
What does each audience care most about?
What do they need to know to be successful?
When do they need to know certain information?
What are the existing or best channels to communicate through?
Who can most effectively deliver the message?
How often should each audience be communicated with?
What do you need from your audiences at different points in time?
In addition to communicating out, it is imperative to listen. Establish a way for your audiences to respond to you. They should be able to provide feedback, voice concerns, and share opportunities you may not know about.
03. Evaluate documentation needs
Useful, timely documentation will enable successful adoption of your app. It will also make a positive impact on your organization’s ability to support the app and expand or make changes to it in the future.
Create a list of the groups who need documentation to create, support, and use the app. For example:
Developer
System administrator
Solution architect
Designer/user researcher
Application support team
Help desk
End users
Talk with the design and implementation teams about what they have documented so far. Ask managers of teams that will need the documentation:
What they need in the documentation
When they need it
How best to deliver it to them
Documentation typically includes design and configuration details. Based on the needs of the project and your organization, capture the work and decisions made.
Your service group or help desk may create their own documentation from training materials.
Identify who is responsible for each type of documentation and communicate this within your organization.
04. Plan end user training
Evaluate what training the end users will need to be successful and comfortable with the new app. Consider what you are implementing, how much change it will bring, and the technical experience and comfort level of the functional group.
Ask the users who will participate in development and testing to help teach other end users about the app. They can help others learn and build excitement.
End users will need minimal training for OOTB apps, which are intuitive. End users can use free tutorial videos to learn how to use the apps.
All users of a custom app will need full product training, as well as an understanding of how the app changes their jobs. This includes IT, admins, developers, end users, and support staff. Decide how and when to deliver training, considering the group’s learning preferences. If available, a learning specialist should work with developers to create the training materials.
Keep in mind the languages of users when you create training.
Confirm the go-live date with the project manager. Choose the best times during the project to deliver the training and start early enough that the training materials will be ready.
Before you go live, determine who will provide long-term support for Windchill Navigate. This will help you prepare for a smooth launch, enable fixes and upgrades, manage access, and stay up to date with the product roadmap.
A custom app will require more ongoing maintenance and a developer. Be ready to support it internally. Since the app is specific to your system and use case, outside support would be expensive and difficult to find.
You may need to provide a light version of end user training to the group who will provide end user support. That way they will be equipped to give support as the app launches.
Reach out to service leads to ensure they are ready to absorb calls and hands-on sessions for Windchill Navigate after go-live.
Finalize Project Plan
Compile the work you’ve done to plan and design your app into one project plan. Get approval of the project plan and budget.
Internal and external staffing resources including professional services and training
Infrastructure costs such as hardware or networking
Software
Licensing
We recommend that you include a 10-15% contingency on your final budget to support unplanned costs that may come up during the project.
02. Document final project plan
Your project plan should provide a detailed view of everything you need to do to complete your project. This plan should include:
Specific tasks
The people responsible for tasks
When each task needs to be completed
Use the documented strategies you’ve created so far as your starting point. No task is too minor to include. Include everything from development and launch tasks to training and communication plans. Include critical project milestones to report back to your stakeholders.
To complete the project phases on time, factor in additional time for complex tasks and make sure the team doesn’t continue to add tasks after the project plan is final.
03. Get approval on the final budget and project plan
Take your detailed costs and final project plan to your executive stakeholders for final review and approval.
Set Up Your Account
Set up the account you will use to download software and get technical support.
You need a PTC eSupport account to download Windchill Navigate software and get technical support. If you already have an account, make sure you can log in.
When you purchased the software, PTC sent a software order fulfillment email. That email contains the information listed above. If you can’t find the information you need, contact PTC technical support.
Follow the plan you created earlier to set up your infrastructure including hardware, servers, and networking. If you are implementing Windchill Navigate via PTC-hosted cloud, you can skip this task.
If you are implementing Windchill Navigate via PTC-hosted cloud, you can skip this task.
Based on the infrastructure plan that you made earlier, set up the servers, networking, software, hardware, and/or devices you need to support Windchill Navigate. If you still need to purchase anything, do it now.
Set up the servers you need for your development environments as soon as possible.
The system admin should lead this work, coordinating with the Windchill admin as needed. Include a Windchill architect if you need to make changes to your Windchill instance.
Prepare to install Windchill Navigate on-premises before you start the installation. Then, follow the instructions to download, install, and configure your software. Work with the PTC Cloud team if Windchill Navigate will be deployed on the PTC-hosted cloud.
Windchill Navigate has prerequisites for installation that the system admin, Windchill admin, and IT team should review carefully. They will need to coordinate work, including installing and setting up hardware, security, and databases.
Work with the PTC Cloud team if Windchill Navigate will be deployed on a PTC-hosted cloud.
We specifically recommend the Windchill Navigate Help Center. You will find prerequisites about licensing, hardware sizing, security, software compatibility, and known issues. Understanding the prerequisites will save you time and prevent errors.
If you will be setting up single sign-on (SSO), there are some specific things you will need to have ready. These include:
A pre-production development environment for each software involved
The software versions for Windchill, ThingWorx, and Windchill Navigate
The operating system ThingWorx runs on
The URLs to log in to your Windchill and ThingWorx instances (including port number)
Windchill and ThingWorx Fully Qualified Domain Names (FQDN)
You can set up SSO during the installation process or do it later.
To install ThingWorx Foundation, first download the software. Then, use the installer to finish installing and configuring. Instructions are available in the article ThingWorx Foundation Installer. Create your own documentation during installation to document your work. Update it as you go.
If you manually install the software instead of using the installer, you will not be able to install Windchill Navigate using its installer. You will have to install Windchill Navigate manually. This is due to different folder structures.
ThingWorx Foundation must be installed before installing Windchill Navigate. To install Windchill Navigate, first download the software. Then, use the installer to finish installing and configuring. Instructions are available in the article Download Windchill Navigate. Your system admin and Windchill admin should work together. Update your documentation as you go.
If you experience any errors during installation, do not continue to configuration. Then resolve the errors and then reinstall Windchill Navigate.
After installation, configure licensing for the software using the license retrieval tool. If needed, you can retrieve the license from PTC License Management (requires login). Note when your license expires to prevent future issues.
If you do not have a full license, you can install a temporary license with a small number of seats to complete the configuration.
Once you have installed Windchill Navigate, configure authentication. Review the plan for authentication that you established earlier. Then follow the instructions in the article, Configure Windchill Navigate. Update your documentation as you go.
If you are using single sign-on (SSO), PTC offers a service to help you set it up called “Configure SSO for Navigate.” Find more information in the services listed below.
Alternatively, authentication can be achieved utilizing Building Blocks. Refer to the Building Blocks Help Center for more information. Building Blocks are the recommended method of development for ThingWorx Navigate.
Set up user groups according to the plan you created earlier. This process will differ depending on whether you are using only out-of-the-box (OOTB) apps or developing a custom app. In both cases, follow the instructions in the article, Modify ThingWorx Permissions: Users and Groups.
Building Blocks can be utilized for user groups and permissions as well. This is the recommended method because features and functions built using Building Blocks can be packaged and exported to other environments allowing for more robust consistency among different environments. For more information about this, click here to learn about Pacesetters and PTC Professional Services.
Once you have set up user groups, add initial users who need access to the app to configure, develop, and/or test it.
Add initial users, including:
Developers who will configure, develop, and/or test the app
Project team members and key stakeholders who will help test the app
Users who will participate in user acceptance testing (typically the same users who helped you test the app design earlier)
ThingWorx includes default user groups with standard user permissions. If you add users to the default group called “Administrators,” those users will have access to everything. We recommend you add developers to that group so they have enough permissions to develop and test the app. They will also be able to manage access for other users.
Check that each user has the expected visibility and permissions. Make any adjustments as needed. Remember to update your documentation as you go.
Once you have installed Windchill Navigate, tailor views or begin custom app development. Use the documentation you are developing to create training materials for end users.
If you are developing a custom app, skip this step.
Tailor views for out-of-the-box (OOTB) apps after you have installed Windchill Navigate. To tailor means to configure or modify views in the app so the right users see the right data. Anyone with administrator permissions can tailor views—most likely the system admin, Windchill admin, and developers. Instructions on how to tailor views are available in the article, Tailor Windchill Navigate Tasks.
Refer to your technical design document and documented user groups to determine what to tailor. Tailor the views you’ll need to properly test the app. For example, if you are using the “View Design Files” task, you can select which formats and design relationships users can see.
Since there are more tailoring options available than you may need to modify, focus on the needs outlined in your use case. Update documentation as you go, including any changes to user groups.
If tailoring OOTB apps does not offer enough customization to satisfy your use case, consider developing a custom app instead. PTC does not recommend customizing OOTB apps if it requires development.
After installation, start development for your custom app. Team members must be familiar with your technical design document and know the plan for source control. That will make the development process go smoothly.
Another options for reusable components, and the one recommended by PTC, is to build functionality with Building Blocks. Building blocks act as reusable components, but the main distinction is that Building Blocks can be exported and imported into other environments. This functionality allows for remarkable consistency across environments. For more information about this click here to read about Pacesetters and PTC Professional Services.
Navigate Components improve and simplify application development because they can be used out-of-the-box to assemble into custom tasks. When you insert a component into a mashup, the component object type and/or behaviors should be further configured. This can be done via the configuration dropdown or JSON for advanced configuration.
The Navigate component's predefined configurations use Windchill as their backend system. Thus, all access control settings, attribute visibility configurations, and security labels that are configured in Windchill are honored by Windchill Navigate components. As a result, users can only see what the Windchill rules allow them to see.
Designers and developers should communicate with one another often to create solutions in consistent ways. Follow best practices for developing in ThingWorx (login required). Update documentation continuously. Make sure documentation reflects how the app was built and the details of the final design. Include as many details about the design and user interface as possible.
When you have built the app, confirm whether it satisfies your use case and user requirements. Iterate as needed. Later, you will test the app more thoroughly.
Create training materials for end users as you tailor or build the app. Compile your documentation to help. The person or group planning organizational change management should lead this. Designers and developers should contribute documentation.
Anticipate that there will be changes to the app as you test it. Make updates to training materials continuously so that they are ready when you launch the app.
Build Integrations
Connect data from Windchill Navigate to Windchill or a third-party system. Once connected, test that data appears and behaves as expected. Test the data connection whether you are using out-of-the-box (OOTB) apps or developing a custom app.
If you are implementing OOTB apps, skip this step.
As you develop your custom app, build the connections between Windchill Navigate and the systems that house your data. A technical developer should build the connections. They should be familiar with the third-party system that houses your data and know how to develop in ThingWorx.
Refer to the plan for integrations you created earlier. Review your plan about what data you need to retrieve and how you will connect. Consider network security and any firewalls or ports that might prevent systems from sharing data in both your development and production environments. As you build system connections, update documentation continuously.
Depending on how the system you are connecting to, PTC has services to help. Find more information in the services below.
After you connect Windchill Navigate to data, test the connections in your development environment. Do this whether you are implementing OOTB apps or a custom app.
Make sure that:
Data appears in the expected format and structure
Data flows as expected among systems
The expected amount of data flows through
Windchill Navigate respects the access controls defined in the source system
The speed is acceptable (the system does not time out before data transfer completes)
Users can access Windchill Navigate (the URL works)
Promote your app to a testing environment and follow your testing plan. Validate that the app works as expected and that users can access the right data. Share the test results with the project team and determine your next steps.
To test your app, deploy code from your dev environment to your test or QA environment. Developers should follow their processes for source control.
Check that each environment shows the appropriate data for the tests you'll do. You may need to remove production data from some environments for integration and system testing. For user acceptance testing (UAT), you should have production or production-like data available.
02. Test and validate the app
Once your code is in a test or QA environment, developers will execute your testing plan. Follow the processes for source control that you established earlier. Do not make any changes to code in a test or QA environment. Changes should be made in your dev environment.
Test every component according to the plan you made, including tests for Windchill. Consider security at every stage. Document code as you write it and record test results. For out-of-the-box (OOTB) apps, update any tailoring configurations on your technical design document. Keep your documentation brief and precise.
If you are developing a custom app, the app is ready for user acceptance testing (UAT) when it successfully passes your integration and system tests.
If you are implementing OOTB apps, validate that the app satisfies your use case. The project manager and sponsor should review your goals and metrics to determine if you will be able to achieve the expected value. If not, consider why and troubleshoot any issues.
Share test results with the project team, including the project manager, project sponsor, system admin, Windchill admin, and IT team. Test results will help you determine next steps.
03. Verify user permissions
To test user permissions, developers should create test user accounts and assign them to each one of your user groups. Use a QA environment that closely resembles production. Then log in as each of the test users.
Verify that the test user accounts can:
Log in as expected
Access the right apps
Access the right data
Take actions in the app as expected
Make any changes to the visibility and permissions of user groups as needed and update your documentation. You may need to make changes to user groups in Windchill Navigate and/or your source system, like Windchill.
If you are developing a custom app, you will do user acceptance testing to further verify user permissions in the next step.
Conduct User Acceptance Testing
Train key users on how to use your custom app and then complete user acceptance testing. Then, review the test results to determine whether you are ready to go live or if you need to make changes to the app first. If you are implementing out-of-the-box (OOTB) apps, skip these steps.
If you are implementing OOTB apps, skip this step.
After integration and system testing, the adoption team (or person responsible for organizational change management) should train a small group of key users on how to use the app. This training will prepare them for user acceptance testing (UAT) in which you will test whether the app meets users’ needs and satisfies the use case.
For UAT, train the users who:
Participated in your wireframe design tests and contributed to the use case and requirements definitions
Are power users who are familiar with the data and whose insights will be valuable during UAT
Are project team members, such as the project manager, project sponsor, stakeholders, and admins
Use the training materials you created earlier and provide documentation to these users as needed.
02. Conduct user acceptance testing
If you are implementing OOTB apps, skip this step.
The purpose of User Acceptance Testing (UAT) is to make sure the app meets users' needs and satisfies the use case.
UAT test results should answer questions like:
Can users use the app and complete the test cases easily?
Does the app solve the problem outlined in the use case?
Is there any data or functionality missing?
Did the app function correctly during the test?
Does the app work on supported browsers?
To get the most accurate test results, complete UAT in a QA environment that matches your production environment as much as possible.
Instruct users to complete the test cases that you wrote earlier. Key users and project team members should participate in UAT. Developers and designers should observe.
03. Validate test results
If you are implementing OOTB apps, skip this step.
Document and review your findings from UAT. Compare the test results to the user needs and the use case you documented earlier. The project team should be involved. Include the project manager, sponsor, stakeholders, IT, admins, developers, and designers.
Discuss whether the app needs further development or if you are ready to go live as-is.
Take extra care to control the scope of potential changes so that you do not end up in a perpetual development cycle without going live. Determine which changes are enhancements or bugs to avoid confusion. You may identify potential improvements during UAT and choose to act on them later, after deployment.
Prepare to Go Live
Make sure the people who will use and support your Windchill Navigate app are ready for go-live. Finalize the documentation, training plans, and communications and add users to the user groups.
Review the documentation plan that you created as part of organizational change management. Gather the final documentation and make these materials available to those who will need them.
Identify and communicate responsibilities for keeping each documentation up to date. If you make changes to the app, be sure to update related documentation so you can continue to successfully support and use the app.
02. Follow communication plan
You will be communicating with all audiences around the time you go live. Follow your communication plan to create the messaging and choose the channels that best fit each audience.
Communications to end users are particularly important. Make sure users know:
How the application will affect their job or role
How to use the application
What training will be provided
How to get help from the support team
Where to access documentation
When the app will go live
If any system outages will happen
A few weeks after go-live, follow up with end users and managers to get feedback on how it is going.
03. Train end users
Deliver training before the app goes live. Follow your training plan.
Set up training including any live sessions as well as communications about self-directed learning, documentation, and other resources.
04. Add end users
If you have not done so already, assign each user to the appropriate user group by following the plan you created.
For both out-of-the-box (OOTB) and custom apps, the administrator is responsible for maintaining user groups and adding users to them.
Prepare and train the teams who will provide technical support to end users once the app is live. They need to know what the app is supposed to do and how to troubleshoot issues such as data connections and user access.
For a custom app, the support team needs to be familiar with the app documentation and understand how the app was built. Though the support team does not need as much training as end users, you may want to share the user training content with them.
Go Live
When you are ready to go live, promote Windchill Navigate to your production environment. Share progress with stakeholders and update documentation. Once the app is live, notify users and teach them how to access the app.
When you are ready to go live, the IT team will promote the app to production. This means to deploy or “publish” the app, making it available for end users. If you’re using PTC-hosted Cloud, work with the PTC Cloud team.
During this process, we recommend the following:
Communicate the timing and progress of the launch to the project team.
Identify the systems that will experience outages (such as Windchill or other source systems) and communicate with the teams who manage or own them so that they can monitor for issues.
Back up the systems involved in case of issues. This includes Windchill Navigate, Windchill, and other systems you are connecting with via custom integrations.
If you need to troubleshoot, do not make changes to the app in the production environment. If you make changes, update your documentation.
Once the app is live, notify the project team and stakeholders.
02. Communicate with users
The person or group responsible for communicating with end users should notify all users that the app is live and ready to use. Refer to your organizational change management plan and follow up on any remaining communication and training items.
Provide end users with the information they need to access the app, whether that is sharing the link or showing them how to access the app online.
Once the app is live, communicate with all users:
How to access the app
What login credentials to use
How to get support and/or training
How to access documentation
How to report issues
Provide Support
The team that implemented Windchill Navigate should troubleshoot and provide support for a few weeks after go live. Once the app is stable, transfer responsibility to the team who will maintain and support it long-term.
Immediately after Windchill Navigate goes live, the developers and IT team who implemented it should be available to resolve technical issues. The group or person who supports Windchill or the third-party systems you have connected to should also be available. During this time, you may need to resolve bugs or network issues. Do not make any changes in your production environment when you fix bugs. Instead, all fixes should go through your testing and validation process. If you need to make user access and permissions changes, you can do that in production as an administrator activity.
Inform the project manager, adoption team, and stakeholders of any major problems or configurations.
Determine whether you will need support outside of regular business hours and who is responsible for those needs. If you thoroughly tested the app before go-live, emergencies are less likely.
The developers and IT team who implemented the app should provide go-live support for the first few weeks. Once you are confident the app works as expected, transition to long-term support. There may be ongoing bugs or minor fixes that developers can address later. Update documentation if you implement any changes.
02. Transition to long-term support
After the first few weeks of go-live support, transfer responsibility of Windchill Navigate to the group who will support it long-term. Follow the plan for long-term support that you created earlier. You may be transferring ownership to your internal IT group, an external vendor, or an adoption team.
The long-term support group will manage user access and permissions (along with the admin), provide technical support, and complete fixes and upgrades. Provide all documentation and training materials so they can assume ownership. We also recommend that you schedule a knowledge transfer session between the development team and the support team.
If the long-term support group needs help with the software, they should first go to:
If they still need help, they can open a case with PTC Technical Support (requires login). The end users should always contact your long-term support group for assistance.
If you need to make changes to the app in the future, always work in a dev environment. Never make changes to code in production. Write code in your dev environment and follow your testing and validation process before you deploy to production.
Going forward, it is important to keep your documentation up to date. Remember to update documentation anytime there is a change, whether it is to a user group or a tailoring configuration.
Revisit the goals and metrics you established for your Windchill Navigate project. Then, gather the data you need to measure success and consider your next steps.
Revisit the goals and metrics you set at the beginning of your project to measure progress and success and revisit your baseline metrics.
We recommend you wait 30-90 days after going live—depending on your use case—to assess the first metrics for the app. While it is likely there will be some improvements almost immediately, some metrics require several weeks of data to accurately measure, especially if any workers are slow to adopt the app.
Compare the baseline metrics to your current data to determine the value of the app so far.
Slow adoption is an indicator in itself. If people are not using the app, consider why they are having trouble accessing the app. Is there a network or hardware issue? Do they need training: Is the app addressing the use case? You can act on some of these factors.
Also account for any unplanned benefits that Windchill Navigate has provided to your organization. There may be measurable or less-tangible value worth highlighting. Based on the numbers and results group managers are seeing, you may want to adjust your value propositions. If so, clearly explain the reasons to your stakeholders.
Share the results and any adjustments to your value propositions with the project sponsor, project team, organizational leaders, group managers, users, and other stakeholders. It is important to share these results so all stakeholders are informed about the value of the app. Reviewing these results can also help you strategize next steps.
You will provide a clearer picture of value if you continue to measure and report over time. Users may turn to the app more often as they get comfortable. They may also discover new ways to use product data. Usage may fluctuate with their need for information.
02. Revisit use cases
After you assess the business value of the app so far, consider how to expand the use of Windchill Navigate to bring the most value to your organization.
You could expand the app to other groups and locations. You can tailor an out-of-the-box app for other roles and users.
Look for other opportunities in your prioritized list of use cases. With the project sponsor and group managers, revisit the prioritized use cases and consider if you would rank them differently today.
To start a new use case and project, repeat the steps of this Success Path.
Do not duplicate or distribute this downloaded file without written permission from PTC.
Use this guide to plan, design, develop, and deploy Windchill Navigate for your organization. Provided are step-by-step instructions, training, documentation, and services to assist.
This information is useful for:
Project Managers
Organizational Change Management Teams
Adoption or Training Teams
System Administrators
IT Teams
Developers
UI/UX Designers
Get started
What is a Success Path?
A Success Path is an online guide to help you implement a specific PTC product at your organization. Each path provides step-by-step instructions from the early planning stages all the way through to deployment. Use a Success Path to help your organization get the most out of a product and achieve your business goals.
Product Documentation
Find step-by-step instructions and information about Windchill Navigate in the Help Centers.
Ask the Community
Visit the PTC Windchill Navigate Community to get product assistance, share ideas, and browse information about using Windchill Navigate.
Technical Support
Log a case with eSupport using your Service Contract Number. Don’t have it? Ask the Community.
Contact Us
Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.
Support Portal
Contact an Expert
Training and Skills
Join the PTC Community