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!

Hi @mfifis  - So we do this for our newsletters. We need to publish them internally, have owners review them and then publish publicly after they are approved. We also need to supply the published links to our marketing team to create email announcements before they are published publicly. It’s a bit of a convoluted process but works for us. Steps are below in case they help you.

1. Create article and publish to a “drafts” category that is only accessible to our “employee” role. example: https://community.acumatica.com/newsletter-drafts-169/acumatica-customer-newsletter-march-2022
2. Take the category name that it will be moved to once approved and replace the drafts category name. In this case the new category will be “acumatica-customer-newsletter-163”. We can then give this link to marketing ahead of publication. example: https://community.acumatica.com/acumatica-customer-newsletter-163/acumatica-customer-newsletter-march-2022
3. Once the drafts are approved we move each article to it’s correct category. example: https://community.acumatica.com/newsletter-drafts-169/acumatica-customer-newsletter-march-2022 is moved to https://community.acumatica.com/acumatica-customer-newsletter-163/acumatica-customer-newsletter-march-2022

Cheers!

Chris

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.