It would be great if a checkbox/select box could be added to the Short URL creation page that permitted a removal of visual formatting based URL variables prior to generating the Short URL. These can cause problems with Short URL markup links embedded in a dashboard page if the dashboard content (specifically visualization layout) changes significantly over time and is re-saved.
Alternatively... the long URL field could be made editable by the user somehow. However, from a usability standpoint it probably is not as straightforward. URL variable manipulation can be tricky for unskilled users.
@nwaringa which Kibana version are you using? we changed the sharing UI in 5.0 to provide a version of the URL without the state in the Share menu -- does that help?

@tbragin, Sorry about that I should have been clearer. The visual state variables that save in the short URL (on the right in your SS) are what can bust a dashboard (things like visualization sizes, positions). However, the query and pinned/unpinned filters that save as part of state are helpful in creating links that can be embedded in markup on the dashboard. This is basically another way to direct users of the dashboard to more advanced filtering that can't be done by simple filter pivoting the visualizations on the dashboard itself. I like to use these to hand hold less advanced users through DB pivots.
I have been embedding these links in markup on dashboards by taking the full link and gutting the visual variables manually (time consuming). However, this leads to two problems 1) lengthy URLS and 2) The need to URL encode (%28 and %29) brackets in the long URL before it is added to my markup visualization.
As I understand it, the dashboard link on the left is merely to share the Dashboard itself (free from any filtering/querying).
@nwaringa, Do you have specific steps to replicate how changing and re-saving a dashboard can bust a shared dashboard snapshot? I ran through some quick experiments but the snapshot url was always as it should be (even if I deleted all the visualizations in the original dashboard, or moved the visualizations around to different positions, then saved, the dashboard from the snapshot url never changed). Saving a dashboard shouldn't affect the dashboard snapshot.
@Stacey-Gammon ... Let me try to reproduce my actions the best I can in this medium (with dummy data in a DB, I can't share our real data DBs).
1) Create a dashboard, add 4 visualizations, and save. Looks like this:

2) Save the snapshot link to the DB (in my case, I copy it and put it in Markup that inevitably ends up on the DB itself)
3) Load the snapshot link up. Everything looks as necessary (sizes appropriate).

4) Load the original DB back up (Open DB).... resize the visualizations on it (add an additional visualization) and save the DB. (edit, missed the new visualization adding in the screenshot...but I did it, and the behavior described below occurs).

5) Open the snapshot link to the DB up. The visualizations (shown below) remain the sizes they were on the original DB creation... not the subsequent save. The dashboard snapshot also drops the new visualization that was added and subsequently re-saved.

I believe this to be perfectly predictable and acceptable behavior if your intent is truly to "Freeze"/"Snapshot" the DB in its current state... Han Solo style. However, all of those panelIndex, size variables, and ultimately missing variables for new visualizations don't help if the intent is to apply new filters/queries to a pre-existing dashboard that evolves with time/development. I suspect there is great utility in the later example. What I am suggesting is to add an option that allows Filters/Queries to be applied to whatever iteration of the DB exists. I believe this can be done by dropping visualization state info. An example of how I apply this:

This example is basic... but as you could imagine, more narrative dashboards that tell a story across the dashboard as links embedded in markup paragraphs could be possible. It's a cheat around saving the DB with a ton of complex filters flipped off that wouldn't otherwise give basic users context about what applying the filter may do to the DB.
Worth noting... my testing was limited to Chrome.
This is a similar Issue to what I am experiencing when creating URL links on the kibana index pattern.
We set certain fields to be a link to other dashboards and use the {{value}} to apply a filter.
I think what nwaringa is saying is that what has currently been done is good if you have no filters.
it would be good if we could use the saved dashboard link and add to the end of it a way to apply filters.
Exactly...or alternatively let the snapshot function exclude any visual snapshot context (and keep the query/filter context). To my knowledge, right now there is no way to create a link to a dashboard filter/query embedded in Markup without either:
1) Embedding the full URL with URL encoded brackets in Markup - Messy and space limited if you use several in a single markup box.
2) Use an external URL shortening service for a dashboard with filter/query you want - Prone to break
Ah, gotcha. Yea, this is how the snapshot feature was designed - it's not supposed to reflect any changes you made and saved to your dashboard. I like @ThomasFlanaghan's suggestion about having an option to include the current filter/query in the url when sharing the saved dashboard url (the links to the left).
We are thinking of ways to improve the embedded/sharing experience, I will add this to our list of considerations.
if the intent is to apply new filters/queries to a pre-existing dashboard that evolves with time/development. I suspect there is great utility in the later example. What I am suggesting is to add an option that allows Filters/Queries to be applied to whatever iteration of the DB exists.
This actually sounds like the drill down links feature: https://github.com/elastic/kibana/issues/12560
Also related: