Create URL before publishing

Hey @mfifis,

While I agree that it would be nice if we could get this functionality too (we would want to embed the URLs into our platform before a feature is released), the “Preview” link will automatically forward to the published link once the draft is published.

I’m always nervous, and try to use the real URL, but it should work for your needs (scheduled posts etc).

Ilan

Thank you, @Ilan B!

Hey @Chris Hackett! Thank you so much for the step-by-step instructions. It’s much appreciated!

You’re very welcome! 

I know this thread is ancient, but this is something that I needed this morning, and I just wanted to express my appreciation. Thank you @mfifis for asking this, and thank you @Chris Hackett for this incredibly detailed and well-thought-out response! 🙌

I too found this topic and found it useful. 

It got me thinking about the structure of the URLs. In the example used by @Chris Hackett the URL don’t seem to have a topic id at the end of the ‘slug’. But for our topics they always have a series of numbers at the end. 

It’s that which means we can’t predict the URL ahead of time, without the suggested workaround of using the drafted preview version and swapping out the category name with the category it will be.

Doesn’t every topic URL have this? 

These are my thoughts exactly 🤔

And great work-around @Chris Hackett!

So it's been a long time but I am not sure why my URLs don't have the ID in my post. They do have them though😏

Hmm.

For example this topic, you are right there is least two urls pointing to opening post:

https://community.insided.com/got-a-question-38/create-url-before-publishing-4653?postid=22964#post22964

https://community.insided.com/got-a-question-38/create-url-before-publishing-4653

But as you can see you can clean the url and get rid of this part:

?postid=22964#post22964

Is there something I am missing now?

--

Edit: I like this workaround but there is one problem - publishing date. I wish that timestamp is just now, not yesterday or day before etc.

Hi @revote,

In your example:

The clean URL has “-4653” in it. 

That’s why using @Chris Hackett’s workaround is needed. As we can’t predict that ID. If the topic URL was just the domain name + folder structure + topic title, we’d be able to predict the URL without the need for the workaround.  

Yes, I see. Sorry, I just answered for this:

As said, it does have but you dont know it beforehand.

Edit: I just thought this more.

Because there is unique numerical id in each and every topic (also posts as well) it makes possible to move or merge topics.

Static numerical id is also needed because it is possible that topic title is changed later on.

And with unique numerical id platform can redirect users from old url to new one.

I think without unique id those are not possible though?

But yeah, problem is that we dont know the id beforehand. We used Khoros before and there is possible to have final url before publishing.

Gainsight team - this should be tablestakes for publishing content. I don’t want to have to take 5 steps to get a URL that I can then plug into an email that I want to schedule. 

Thanks for this workaround! The only downside to this, is that you'd have to publish the article already. Sometimes we're preparing topics a few weeks before publishing. Then it would be useful to be able to predict the URL, to share with other colleagues.

But when using this hack, the topic could be weeks old before we really ‘publish’ it. Personally, I think it's not so nice to share a ‘new’ topic this way, because the time stamp of publishing says a few weeks ago, then it doesn't feel like a new article the moment we make it visible for our community users.

​@Alexandra_ Another great point! All together not being able to have an article in draft with a URL is a miss - and it feels like it should be such a simple thing to fix.

​@Gainsight CC Team are we missing a better way to deal with this? 

Hi ​@kateressler - at the moment the best approach is the one already mentioned, where you first publish into a drafts category.  Technically, you don’t need to go through the other steps described above to update the URL, as our platform has permanent re-directs for any topic that gets moved from one category to another.  So you can simply use the link from your drafts category and move the topic later - that link will always work.  It might feel or appear less clean, though, which could be a good reason to go through the above steps anyway.  The only other alternative I can think of would be to create a link up-front that you share with your colleagues, and then at the time of publishing the article you create a redirect to the article from the link you shared.  This can be done with a bit of script in the Third Party Scripts section, but I wouldn’t recommend doing this often or at scale (could be handy in an emergency though). 

I’ll ping our Product team to remind them of this use case.

​@Kenneth R has the product team ever chimed in on this. I am asked this all the time. To draft articles, share the link to the article so they can have a different blog drafted with links to my blog ready to go. 

I'm interested to know this, as well. 

We often publish articles about something the company does that has to coincide with other  communication, and is referenced by that. To make sure all communication goes live at the same time, we now often have to use the preview url as a link in the other communications that refer to our article.

Besides the fact that using the preview link looks ugly, it also looks like phishing.

Especially in an age where digital safety is a key feature, using a link that looks like a phishing link in communication that goes to our customer base is not done.

The work around of publishing the draft in a secret category is not a viable alternative. If we then move the article to a public category on release, it is no longer ‘new’ content.

We’ve run into this a few times when trying to coordinate a launch across different channels. It’s a bit of a workaround, but usually, the URL follows a predictable slug based on the title you give it. If you save it as a draft first, you can sometimes see the intended path in the backend, but having a dedicated 'copy link' button before the official publish would save a lot of guesswork. It definitely makes it easier to prep emails or internal docs without waiting until the very last second to grab the live link.

The article/blog feature needs an update.

Could use options like:

Add canonical url, back date posts, etc - basic features found in Wordpress.

Thanks for keeping this thread alive and for the detailed feedback. This is super useful!

I wanted to share that we're exploring a content publishing workflow later in 2026 that would introduce draft, review, approval, and publish states for articles. As part of that work, we're planning to look at pre-populating a permanent content URL at the point of draft creation which should address the enhancement request here. The concern around publish date would be resolved with that approach as we would ensure that the publish date is the “post date”, not the draft date.

Nothing to commit to just yet, but I wanted you to know this is on our radar and that the use cases you've described (coordinated launches, sharing links before publish, avoiding the preview URL workaround) are exactly what we're designing around.

Thanks for sharing ​@Larry sounds exciting! 

That’s exciting to hear ​@Larry!

We currently use the solution identified in this thread too when we need to provide a URL before a topic is ready to be customer-facing: Publish the topic in a secret drafts category, predict the final URL by manually replacing the draft category with the intended category, then manually move the topic into the intended category once we have approval.

Very good, and exciting to hear, ​@Larry! Looking forward to seeing what you guys come up with. And we're always up for beta testing :D