I'm Forrest Falk, a ServiceNow Certified Master Architect (CMA). In this post, I'll share practical insights from a CMA’s perspective and show how to use build agent to create, edit and deploy full stack ServiceNow applications that encompass front and backend components. This post is part of a series, and I will be posting updates as I go along. Each post I will be sharing my experience with build agent and add more features. I will cover starting from scratch to how to edit our application.
View part 1 here: Creating an application with Now Assist Build Agent - Part 1
View part 2 here: Creating an application with Now Assist Build Agent - Part 2
View part 3 here: Creating an application with Now Assist Build Agent - Part 3
View part 4 here: Creating an application with Now Assist Build Agent - Part 4
Hello everyone, and welcome back! Today, we'll discuss updating the tables behind our dashboard so that, instead of using scoped application tables, they'll reference the Hardware Asset Management (HAM) tables currently used by the HAM module in ServiceNow. This change will ensure continuity across ServiceNow modules, bringing us closer to out-of-the-box functionality by unifying our data system-wide. As a result, our workflow will become simpler with less maintenance required in the future. Below is our previous dashboard, which still uses the scoped application tables.
I'm testing the Build Agent's capabilities by asking: "Is it possible to switch the data tables behind the dashboard to those used for hardware asset management?"
The Build Agent explains the available HAM tables and asks if I want to use them. It also mentions updating UI components and field mapping for integration with the dashboard. I agree, so it will now use the relevant asset and CMDB tables.
After completing the changes and approving their deployment, I returned to my dashboard. Upon loading the dashboard, I encountered an image indicating that storeroom data was being loaded. This occurred because all of the hand tables are now connected, resulting in a significant amount of data to process. As the dashboard loads, it may take some time. This is especially since, on my demo instance, these tables have not been accessed frequently, so some caching is likely occurring during this initial load.
Now that it’s loaded, we can see the dashboard displaying actual data: 54 storerooms, around 2,600 items, about 200 low stocks, and roughly 300 unique items. This demo uses much more realistic and extensive data than before, making it even better for presenting to clients. Nothing makes for a better demo than using the clients own asset data sets if you can.
After these changes, I can no longer click on totals for storerooms, items, low stock alerts, or unique item type buttons to see their respective lists in the dashboard. I want the dashboard to show an easy-to-read list when I click these buttons/areas, so I’m updating my prompt to be more specific about this request.
After implementing the updates, I checked the storeroom interface and noticed that both storerooms and their items appear much more clearly and are easier to read. When you select "view details" for any storeroom, you can see exactly which items that storeroom holds. Everything is working smoothly following these changes, and I’m thinking about adding color or other enhancements in the future to make it easier to read. Please share any suggestions you might have.
In the next post, I I’ll look onto what other features we could add to our dashboard and find tuning some of the books that we have today.
