- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Report Name: Net Monthly Service Catalog Tasks Overview
Problem: Scheduled email sent null attachment with warning "The sender does not have access to this report"
- The report "Net Monthly Service Catalog Tasks Overview" is domain-specific to Net
- When "Run as" user is not from the Net domain, the scheduled job cannot access report data
- System generates null attachment with error message: "The sender does not have access to this report"
- Before Run as user is system admin which have all required role but not from Net domain. to resolve this issue, we have change run as user with XYZ user who is from Net domain. after Australia release, we face this issue.
Anyone has idea about this issue. If yes need your help to understand the issue.
Thank You
#servicenow
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
The Australia Domain Separation release notes mention changes including domain-visibility query optimisation, dot-walk scoping compliance and Java 21 support, but not this exact scheduled-report behavior.
Is changing the Run as user correct?
Yes. Changing the Run as user to someone from the Net domain is the correct immediate resolution.
However, using a named user such as XYZ may cause another failure later if that person:
- Leaves the organization
- Becomes inactive
- Changes domain
- Loses a required role
- Has their access modified
Recommended permanent solution
Create a dedicated service account, for example:
svc_net_scheduled_reports
Configure it with:
- Domain: Net
- Active account
- Minimum required reporting role
- Read access to the underlying Service Catalog Task table
- Required field-level access
- report_view permission
- Access to the report through user, group or role sharing
Then configure this account as the Run as user for all Net-domain scheduled reports.
Avoid giving the service account the full admin role unless absolutely necessary.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
I can't speak specifically to an Australia upgrade but there is definitely and ACL type out there for running of reports against data - "read" doesn't cut it, there's something like "report on". Try adding an ACL for that table that gives the user you are running the report as that access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
The Australia Domain Separation release notes mention changes including domain-visibility query optimisation, dot-walk scoping compliance and Java 21 support, but not this exact scheduled-report behavior.
Is changing the Run as user correct?
Yes. Changing the Run as user to someone from the Net domain is the correct immediate resolution.
However, using a named user such as XYZ may cause another failure later if that person:
- Leaves the organization
- Becomes inactive
- Changes domain
- Loses a required role
- Has their access modified
Recommended permanent solution
Create a dedicated service account, for example:
svc_net_scheduled_reports
Configure it with:
- Domain: Net
- Active account
- Minimum required reporting role
- Read access to the underlying Service Catalog Task table
- Required field-level access
- report_view permission
- Access to the report through user, group or role sharing
Then configure this account as the Run as user for all Net-domain scheduled reports.
Avoid giving the service account the full admin role unless absolutely necessary.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
@Suryansh Verma Hi, if you have any kb article around this could you please share it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago