At the 2024 COExperience conference, Bellflight’s Andres Mora and Jason Jorgenson presented the session "Leveraging 3DX Custom Widgets for Supplier Collaboration,” which was popular with attendees. In this article, they share answers to questions they commonly receive regarding this topic.
Q: Why create custom widgets instead of using out-of-the-box (OOTB) widgets? How was it determined that these were needed?
A: The OOTB package comes with some very useful widgets that help the company with the PLM cycle — widgets like Collaborative Lifecycle to change object maturity or change object ownership, IP Classify & Reuse to add a part/assembly to a library, Engineering Release, which allows users to create parts and assemblies and manage BOMs. These are all great tools that help engineering accomplish their tasks.
However, when getting together with subject matter experts (SMEs), stakeholders and developers, it was determined that these were not enough to satisfy the business needs. An example of this is the lack of a technical data package solution which led to the creation of three of our custom widgets. Disciplines other than engineering needed a way to see only relevant data without having to click through multiple widgets. This need led to many of our one-stop-shop widgets where the user is limited to only a few widgets or sometimes only one. This was crucial with supplier collaboration to avoid confusion having to navigate to multiple windows and limit their access.
Q: How can suppliers see these widgets? How do they know what widgets they have access to / can use?
A: All widgets can have their own access designed into them. For widgets that have supplier specific functions, it was determined that if a user was logged in through a supplier account, that user would end up having direct access to the widgets created with the supplier login access. This ensured that regular users within Bell would not see the supplier widgets and suppliers would not see Bell user specific widgets. Using NDAs and IP/XP and ACAB controls, we were able to ensure that users logged in through the supplier accounts were only able to see the data that was specific to that company.
If a widget was created that needed a specific role or license to be able to access the widget, only those users with the necessary roles or licenses would have the permissions granted to them to be able to see the widget. For example: a widget may be designed so that only users with Company A logged in as a leader should see the widget. If one of the companies’ users only had access to a contributor login role, they would not be able to see the designated widget
Q: Is there a standard template used to create these widgets? Are there advantages in having one?
A: One of the main advantages of using custom widgets is the ability for the developers to be creative, which itself could lead to five developers having five completely different widgets. Having a standard template is useful in having some level of consistency in widget creation. Not only does it minimize development work when a template can be shared, but also is useful for the end user to have some level of familiarity when going from one custom widget to the next. This is very important in the case of widgets created for supplier collaboration as it minimizes confusion when performing their required tasks.
Q: What were the biggest challenges?
A: One of the biggest challenges was realizing that a standard widget template should have been implemented from the beginning of Bell’s foray into the customization of widgets themselves. We had three separate teams working on individual features throughout our AGILE Product Increment releases. Only when the larger capabilities had smaller features that began to blend functionalities together did we realize that a common “feel” for the team’s widgets would be more beneficial to the end users. After the teams realized this, the teams started designing subsequent widgets with more standardized feel and design to them.
Another big challenge we ran into was testing widget functionality with the correct licenses and roles granted to them. We had accidentally made the mistake of testing widget functionality with a test account that had access greater than what was intended for our production environment. This was only brought to our attention after a production release when our first supplier ran into issues. Thankfully, through IP/XP, ABAC rules and NDAs, there was no issue with the companies accidentally being able to see data they shouldn’t through the separate widgets UI. Testing with the larger access roles, e.g., leader vs. author, only affected permissions such as approvals and upload capabilities. If you decide to go down this route, just make sure you do your specific testing with an account that has appropriate roles and licenses. It will save you from major headaches down the line.
Jason Jorgenson is a senior engineer and 3DX Power User for the PLM group at Bell Textron. He worked as a product owner at Bell for over three years helping lead an Agile team of developers to implement business functionality in 3DX through implementation of widgets and interfaces. Previous work experience includes design for custom aircraft interiors on 737 and 777 platforms as well as R&D for SATCOM antenna design for Boeing, Airbus and Bombardier platforms.
Andres Mora is a principal engineer and 3DX Power User for the PLM group at Bell Textron. As a product owner for over three years, Andres co-led a team of software developers for 3DX during Bell’s upgrade of their PLM solution. He also has extensive experience in airframe/structure design across multiple programs including Boeing’s 787, Bell’s 525 and Bombardier’s Global 7000.