Get public URL before publishing

You got my vote!

Mine too! Can't believe this wasn't an idea already tbh.

The problem with that work around is that the publish date is older when you actually move it to the public section. Not pretty imo.

Other (ugly) work around: The preview url gets a redirect to your published article. So you can share the very very long preview url beforehand.

Hi @mbonnell! Thank you for sharing this suggestion! I am wondering where would the draft link be referenced before publishing? Is your use case around creating a set of draft articles which would link to one another? We could consider a solution around generating the topic URL before publishing, though I’m not entirely sure it is feasible as the URL contains the topic ID which is generated at the time of publishing the content to avoid conflicts with other topic’s ID. 

The workaround @Paul_ mentioned that might solve the issue you’re encountering, especially if you use it in a hyperlink so the readers do not see the long preview link. Once the draft is publish, you will not need to update it because it will automatically redirect to the published topic’s URL. 

Other marketing and product efforts, for example, email campaigns, marketing websites, in-product links to additional information and content. As a broad example, our general flow for releasing a product change is:

a) beta test as employees
b) ship product change to production
c) ship marketing updated
d) ship community posts/information

b and c will often contain links to the community posts, but we have to re-deploy b and c after the community posts are live due to not having a trusted URL that can be used. We don’t want someone to go from a marketing email or marketing website to an invalid URL, but are forced to take that risk due to a lack of a definitive URL being presented. 

Could the topic ID be generated at draft time to avoid the conflict?

I see, the issue is that users will arrive from external sources on a page that will show the 404 error. Even if we would be able to generate the exact URL of a topic before it’s published, users will still not be able to see the content until it is actually published, because the “published” state is what makes a content piece visible to community visitors. I’m afraid your problem would not be addressed, if I understand it correctly.

Please let me know if I’m missing something in defining the problem you’re encountering. 

Thanks @Cristina, the URL is still valuable because then we don’t need to do a re-deploy of marketing or production systems with the correct URL. To be super explicit:

1) Without a valid draft URL:

• The community page doesn’t load.
• Marketing resources don’t have a valid URL
• Product resources don’t have a valid URL
• After releasing community posts, marketing and product have to re-deploy as we couldn’t give a URL in advance which takes time dependent on how long code reviews, builds and deploys take.

2) With a valid draft URL:

• The community page doesn’t load.
• Marketing resources have a valid URL (that would 404)
• Product resources have a valid URL (that would 404)
• After releasing community posts, everything works.
  
   

@mbonnell clearer now, thanks! Just one more small follow-up 🙈 Could you share what do you mean by “valid draft URL”? Why isn’t be the preview link a “valid draft URL? 

Here’s an example preview link:

https://community.IntentionallyReplaced.com/preview/article/224?t=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b3BpY0lkIjoiMjI0IiwiY29udGVudFR5cGUiOiJhcnRpY2xlIn0.622F8aT45WN-liQyBtRYCoMr47WxW-CiQXSfqNJ1z98

When this page goes live, based on other examples, I think the page will be:
 

https://community.IntentionallyReplaced.com/article/community-area-location-number/title-of-post-plusuniqueIdNumber

Aside from removing /preview/article/Number and the very long string thereafter, the final URL doesn’t look anything like the draft URL. 

https://community.IntentionallyReplaced.com/preview/article/224?t=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b3BpY0lkIjoiMjI0IiwiY29udGVudFR5cGUiOiJhcnRpY2xlIn0.622F8aT45WN-liQyBtRYCoMr47WxW-CiQXSfqNJ1z98

https://community.IntentionallyReplaced.com/article/community-area-location-number/title-of-post-plusuniqueIdNumber

I agree. Reserving a short/def. url before publishing would make it a lot easier if other teams need that url for their content. Be it marketing for a newletter or another online team that whants to link to the article. It makes ‘going live’ at the same time easier. The preview url works, but it is long, it says “preview” in it and it is not very SEO friendly to use redirects. I don't think it's designed to use it that way(?).

I just started using this recently and was surprised that this feature wasn't available!In our company, we need to provide topic URLs to other departments in advance.Manually changing URLs is very dangerous.This is an old post, but I would appreciate your consideration.

See this recent post for some good news :)

​@Erik_ Thanks for letting me know. I'm really looking forward to the update.

Thanks for this idea and to everyone who's contributed here.

This is being tracked alongside a related idea and we're moving it into discovery as part of broader content workflow improvements. The ability to get a stable, production-ready URL before publishing is a clear need for teams coordinating community content with external campaigns and deployments. We'll keep this thread updated as we learn more.

Exactly! I have to provide our development, Marketing, and Product teams with REAL URLs during the development cycle. Which means, I can’t use Drafts and must create hidden Categories so the articles aren't where they are supposed to be and must be moved post-release (which changes the URL, but if one uses a shortened URL with JUST the Topic ID, it works...) but it’s a PAIN.

​@danielwal_coco  Completely understand, I’m investigating as part of the broader content workflow improvements we are planning this year. I will do my best to try and deliver this one earlier if possible given the pains communicated by everyone on this idea.

One other thing, when creating a new article, it’s Topic ID (for Insided’s backend) should be the same Topic ID that the front end uses.

Great callout, agreed, we need to make this consistent between surfaces (backend and frontend)

Great callout, agreed, we need to make this consistent between surfaces (backend and frontend)

On the topic of IDs I’d also like to propose removing the numerical ID from the URL altogether--or at least providing that as a configuration option. The URLs would be much more predictable if you could expect the final output to just be the hyphenated topic name, without any system generated ID appended.

​@judahs The IDs might become more predictable, but in my experience, the numerical ID plays a big role in ensuring that if a URL changes, old links to the content don’t break. This has been huge for us as we’ve reorganized the Community several times as content needs, lines of business, customer base, etc., all evolve over time. We know we can rename a Knowledge Base and trust that we don’t have to do a site-wide link analysis. 

But that said, all the more reason why the backend and frontend IDs should be consistent, so +1 from me on that as well. 😅

I will ask our engineering team about this but I have a hunch that ​@atwhite is right, it may be difficult to accomplish but it all depends on our technical architecture. Still, worth asking and exploring the pros and cons of that approach. It’s more readable / predictable from a human perspective but the research I’ve done already indicates that it is not a huge impact to SEO having numerical ID’s.

This a very good point, I am actually curious to learn more about the role of that ID and what role it plays with permalinks. I know that topics have two IDs, a public and a private ID. The public ID is what gets appended to the topic slug in the URL, and the private ID functions like a permalink in some way. I don’t know much about it, they work something like this: 

URL with public ID:

https://community-name.com/category/topic-name-[public-id]

URL with private ID: 

https://community-name.com/articles/[private-ID]

Unfortunately, I don’t think there is any way to find a topic’s private ID in Gainsight CC. We have Gainsight CC integrated with Gainsight CS instance, so I can report on community objects in CS and find a topic’s private ID there.

I’ve actually started using the private ID URL format above when someone needs an advance URL to use in a newsletter or a popup build since it’s a permalink. That way all I have to do is just push the topic up to my hidden “drafts” category in the knowledge base and then get its private ID. I don’t have to manually build a URL myself with the category I know it’s eventually going to move into. It’s still a manual workaround, but less opportunity for me to make a typo I guess 🤠

​@Larry if the numerical ID in the slug can’t be removed easily, another improvement might be to just surface the article’s private ID in control somewhere so that type of a permalink URL could be used even if an article can’t be published/visible right away. 

​@judahs I hear you and it is an approach I’ll ask my team about. We are going to be working on requirements for a broader content publishing workflow soon and I’ve already been planning to fold this idea into that. Once I have an approach decided upon and a timeline to announce, I’ll post it here!