Showing results for 
Search instead for 
Did you mean: 

Hidden pages are still accessable by users via URL

If you publish a report to an App, each report page has a unique URL.  If you later on mark that page as invisible and then update the app, that page is still accessable via that URL.  This is a problem due to users frequently using Browser Bookmarks, even when requested not to.


The use of hidden pages is important with template and expansion of reporting.  We have had users get access to incorrect information due to the use of bookmarking.  Users should never be allowed to view hidden.  Access to hidden pages should either produce an error, or redirect the user to the first visible page on the report.

Status: Accepted
Community Support

Hi @Ross73312


I have reported this issue internally: CRI 159154977. Will update here once I get any information. 


Best Regards,
Qiuyun Yu

Community Support
Status changed to: Accepted
Advocate I

Whoa, hold on on fixing that, by the way. This is actually a "feature", with at least three use cases: 

  1. Drillthrough tool-tip page - you want that hidden AND reachable. It makes no sense without the source filter context. You do not want users to just be able to navigate to it without drilling through.
  2. Group-specific page visibility. I.e.  - need to show a page on a report to some, but not all users? The only solution, at this point, is to hide that page, then point a dashboard to it, then share the link to that dashboard to your target audience. 
  3. Conditional page navigation  - Have a button/object that point to pages A/B based on some condition? Build the A/B, hide them, build a pointing measure, done. Again, you don't want ether A/B to be normal-visible to avoid user confusion.

Now, here is a possible solution you should try - duplicate your page, delete original, rename the duplicate, republish. This should reset GUID for that page, causing the user links to fail.  BTW, linking to a non-existent section of a valid report GUID = user lands to the first page of that report. Structure accordingly.

Community Champion


In this particular case that wasn't possible.  We have a set of templatised reports that have expanded greatly covering multiple countries each with localisations.  The problem that identified this issue was that an original report had a single currency, but the template was expanded to cover multiple currencies.  From here reports are split down into their localised versions from the main master file.  This meant that the stored URL took users to the previously accessible currency instead of the main currency for that region.  That region uses the same currency symbol compared to the main sheet so it was not easily identifiable to the report viewer.


Hiding of report pages is important to restrict access to pages without the requirement to deleting them.  This is important. We need to be able to hide a page and keep it out of user's access.  This is doubly important if we have to take a page offline temporarily for updates/fixes.

Advocate I



I see your pain. I wonder how the dev's would have to balance all those use cases. 

Community Champion

@AndreyBear  To me the simple solution is to provide a checkbox on publishing that allows the selection or not.  Something like "Allow users to select hidden pages in Exports", then provide that option to the users only if it has been turned on.  I feel this would satisfy us both.  I could disable it on all my projects, but you could turn it on for yours.

There are already checkboxes when publishing apps that let us choose whether they can connect to datasets, so there is a precedent.

Advocate I

@Ross73312 , @v-qiuyu-msft 


Yes! And it would be even better if that option was page-specific.  

Community Champion

@AndreyBear  Perhaps the better approach would be to have 2 different hide options per page instead?  A "Hidden" and "Invisible" page toggle.  Hidden pages are not exportable, invisible pages are.  That would save unecessary checkboxes and give the power to the report creator.