Troubleshooting Access with Smarter Prompts

By now, you've built a solid foundation for prompting AI about Workday. You've learned to start with objects, set your role context, use Workday-native action verbs, specify exact output formats, and stack constraints for precision. You're getting deployment-ready responses. Your prompts are sharper. You're building calculated fields and reports faster than ever. 

But then this happens: you know the data exists, your prompt is perfect, and your report returns absolutely nothing. I was building a termination dashboard when I ran into this. And it taught me the sixth element that can make or break any Workday prompt. 

The mystery of the missing terminations

Our HR business partners swore they had offboarding activity last month: fifteen people across three divisions. But my matrix report showed zero terminations. Not partial data, not incomplete records. Zero.

I followed a five-step framework to prompt Mando AI on how to build it perfectly: 

1. Object: Worker ✓ 

2. Role: "As an HRIS Analyst" ✓

3. Action verb: "create" ✓

4. Output format: "matrix report" ✓

5. Constraints: "last quarter, by location, excluding contractors" ✓

My first instinct? Blame the data. Maybe the termination business process wasn't closing correctly. But when I checked the Worker transactions, everything looked fine. Terminations were flowing into the system with proper effective dates and reason codes. So why was my report completely empty? 

The hidden barrier: security domains

Workday veterans know this pattern: if you can't see data in reports that you know exists, the problem usually lies in the security context.

Every field you pull into a Workday report inherits visibility from one or more domain security policies. Termination information touches multiple domains: 

• Worker Data: Terminations – for core termination details like reason codes and dates 

• Worker Data: Historical Staffing Information – for access to viewing/modifying workers' historical information, including termination events

• Trended Worker Data – for indexed historical and analytic reporting on terminations and turnover across organizations

If your position (via role-based security) or Workday account (via user-based security) doesn't have access to those domains, the fields simply don't appear. No constraint stacking, format specification, or clever calculated field will bring them back.

This is where the sixth element becomes critical: referencing security context in your prompts.

My prompt that didn’t work

I asked Mando: 

"As an HRIS Analyst, create a matrix report showing Worker terminations by Location over the last quarter, excluding contractors and interns."

Object? Check. Role? Check. Action verb? Check. Format? Check. Constraints? Check.

The response was technically perfect:

• Recommended "Business Process Transactions (Indexed)" data source 

• Suggested Location as row grouping, Calendar Quarter as column grouping

• Provided calculated field logic for contractor exclusions

• Outlined matrix summarization setup

All correct guidance for building the report. But when I implemented it exactly as Mando suggested, I still got zero results. The AI assumed I had access to the data. It never occurred that the problem might be access permissions.

The prompt that unlocked the data

I tried again, this time adding the missing ingredient… security context:

"As an HRIS Analyst, create a matrix report showing Worker terminations by Location over the last quarter. If I can't see termination data, what domain security policies should I check?"

This significantly elevated Mando's response. Instead of jumping straight to report configuration, I got comprehensive security diagnosis in the response:

• Multiple domain options: "Check domain security policies such as 'Staffing Actions: Termination Details,' 'Worker Data: Public Worker Reports,' 'Worker Data: Active and Terminated Workers,' and 'Worker Data: Terminations'"

• Data source adjustment: "Use 'All Active and Terminated Workers' data source" with specific filtering guidance

• Verification steps: Detailed breakdown of which domains control access to termination dates, service dates, and historical staffing information

• Implementation reminder: "After making security changes, activate pending security policy changes"

But here's what made the difference: Mando didn't just list domains. It explained that different aspects of termination data require different security access: basic worker data, termination details, service dates, and historical information each have their own domain requirements.

That was my breakthrough. The problem wasn't report design or constraint logic: it was access.

Why security context changes AI responses

Adding security context doesn't just get you troubleshooting tips; it fundamentally changes how AI categorizes your question.

• Without security context, Mando assumes you're asking about report mechanics and configuration.

• With security context, Mando knows you might be blocked at the access layer and focuses on diagnosis first, implementation second.

This is especially critical because security restrictions in Workday are invisible until you hit them. Unlike syntax errors or configuration mistakes, domain security just makes data disappear silently.

Here's how security context integrates with the framework you've already learned:

• Base prompt structure: "As a [ROLE], [ACTION VERB] a [FORMAT] showing [OBJECT] [CONSTRAINTS]"

• Security-aware enhancement: "As a [ROLE], [ACTION VERB] a [FORMAT] showing [OBJECT] [CONSTRAINTS]. If data is missing, what domain security policies govern access to [SPECIFIC FIELDS]?"

Here’s an example to try:

• Before: "As a Compensation Analyst, create an advanced report showing Worker salary changes over the last fiscal year for Directors and above."

• After: "As a Compensation Analyst, create an advanced report showing Worker salary changes over the last fiscal year for Directors and above. If compensation data is missing, what domains control access to salary history?"

Same business need, but now you're getting diagnostic guidance alongside implementation steps. These patterns consistently surface access issues before you waste time on configuration:

• For missing fields: "As a [ROLE], identify which domain security policies control access to [SPECIFIC FIELD] on the [OBJECT]."

• For empty reports: "As a [ROLE], explain why I can't see [FIELD/DATA TYPE] in [REPORT TYPE], and which security groups would provide access."

• For business process access: "What domains govern access to [BUSINESS PROCESS] data, and how can I verify my current role permissions?"

• For comprehensive diagnosis: "As a [ROLE], list the security reports I should run to diagnose missing data in [FUNCTIONAL AREA]."

The pattern builds on everything else: start with your role, use the right action verb, but add the security diagnostic angle.

The real payoff: faster diagnosis

After my security group was updated with Worker Data: Termination access, I re-ran the dashboard. All fifteen missing terminations appeared instantly. No report rebuild, no business process fixes, no constraint adjustments.

But the bigger win was efficiency. Instead of spending hours debugging report logic that was never the problem, I diagnosed and fixed the real issue in minutes.

When I delivered the corrected dashboard to HR, they didn't care that it was a security issue; they only cared that the numbers were finally accurate. But I cared that referencing security context in my Mando prompt saved me from another afternoon of unnecessary troubleshooting.

Integrate everything you've learned

Security context isn't a replacement for the other elements; it's a diagnostic layer that sits on top of them:

• Objects and role context tell AI what you're trying to build

• Action verbs and output formats tell AI how to build it

• Constraint stacking tells AI which population to include

• Security context tells AI to check if you can actually access the data

This creates a complete diagnostic and implementation framework: "Build this specific thing for this specific population, and if it doesn't work, here's how to figure out why." 

What's next

In our next and final post of this series, we're exploring the last piece of the puzzle: using examples and expected logic to get Mando to walk you through not just configuration steps, but sample values and outputs that prove your logic works correctly.

For now, try this experiment: take your next troubleshooting prompt and add "If data is missing, what domain security policies should I check?"