Hey @mbuuck1 ,

Unfortunately this isn’t possible right now.

What would be the use case / benefit of an exact placeholder URL for you here? I know the preview link that is generated right now is pretty long and ugly but it would be good to know more context here.

The only workaround I can think of to have a more friendly URL is to publish drafts in a dedicated gated category until they are ready to go live and be moved into another category (which I admit kind of defeats the point of the draft functionality).

We do have this open idea in the community but I’ll also feed this back to our Product team internally:

Thanks @olimarrio, I’ve upvoted that idea you linked to. 

I’ve considered that workaround you mentioned, but the other problem with that (apart from losing out on the benefits of the draft functionality) is that the URL of the article always includes the name of the category that it was published in. So, even if I did publish it in a separate, dedicated drafting space, the URL would still change to include the name of the “final destination” category, thereby breaking the “draft” URL. 

More about our use case:

We frequently use the community for small announcements and updates that don’t justify a full new knowledge base article. These announcement posts are often included in other teams’ collateral, such as emails and blog posts, which also have to be prepared ahead of time, so we need to provide the URL of the post to them in advance of the post going live. The reason that the current placeholder isn’t ideal is that it makes tracking extremely difficult, particularly in terms of understanding traffic from a particular source. 

Hi @mbuuck1 - We have a similar need and I posted a reply awhile ago on what we do to get around it. Maybe it helps.

Thank you so much @Chris Hackett - I had actually tried this exact thing, but unfortunately I’m running into the same snag that others on that thread are experience. Because I don’t know the unique post ID in advance, I’m unable to completely pre-build the URL. Your use case is very similar to mine, though, and I’m glad to hear that our thinking aligns!