Last time we met the Analytics Solution Consultant, the strategist of the group. This one's the workhorse, and if you run PeopleSoft, you already know the pain it's aimed at.
Thousands of PS_ tables. Cryptic field names.Knowledge locked in one DBA's head. And the vendor cataloging tool is either out of budget or out of scope. So the data dictionary that everyone agrees you need never quite gets written.
How the agent helps
The Data Dictionary Builder works like a cookbook. You're not asking Copilot to magically know your schema. You're giving it the recipes. It walks whoever's doing the documenting through pulling structure straight from PeopleSoft's own metadata tables: PSRECDEFN for records, PSDBFIELD for field attributes, PSDBFLDLABL for the field labels, and PSXLATITEM for translate (lookup) values. Then it helps map those technical names to plain-English business definitions and drop them into your standard template.
Some of what it can field:
• How do I extract a list of all tables and fields for the HR module from PeopleSoft's metadata tables?
• Which system tables hold the field labels and translate values I need to write definitions?
• What's our standard template and naming convention for documenting a new table?
• How do I find which records use a given field across the environment?
The honest part
The agent does not write your dictionary for you. PeopleSoft's catalog gives you structure, including names, datatypes, labels, valid values, but it can't tell you what a field means to the business, who owns it, or whether it's even populated in your configuration. That curation is still human work. What the agent does is make the mechanical part fast and consistent, so your team stops re-deriving the same SQL every time someone new picks up the task.
Two things worth including in your cookbook so the result is useful instead of overwhelming: a row-count or last-updated filter so you only document tables you actually use, and a business-definition column that the agent prompts a human to fill in. And one PeopleSoft-specific guardrail which is to tell the agent to remind users to validate SQL against your PeopleTools version, since things like translate-value storage have shifted across releases.
What you need
Same recipe as before: a SharePoint site holding the cookbook (your SQL recipes, naming conventions, and the dictionary template), a Copilot license to build it, and permissions scoped so only your team sees the SQL.
Once you can finally see your data clearly, the next question is whether you can trust it. That's where the third agent comes in.