Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3157 Ideas

    ClarkNew Participant

    View @ mentions when conversation access for a role is set to "Conversations assigned to them only"Submitted

    Hi everyone,We’re currently optimizing our assignment workflows to improve team efficiency and eliminate cherry-picking.To ensure a fair workload, we want to restrict our Specialists' view by setting Role > Conversation Access to "Conversations assigned to them only." This forces the team to rely purely on balanced assignment or the "Pull" feature within their personal inboxes.The ProblemOnce this restriction is enabled, Specialists cannot view conversations where they are @mentioned unless the ticket is explicitly assigned to them.I understand why this happens technically (they don't own the conversation), but it completely blocks our internal collaboration.Why This MattersWe are onboarding more departments into our Intercom workspace, making cross-functional collaboration vital. Currently, we are forced to choose between two options that don’t suit our needs: Allow cherry-picking just so the team can collaborate via @mentions. Stop cherry-picking, but completely isolate our agents from internal help. Desired OutcomeWe need a way to bypass the "assigned only" restriction specifically for @mentions. Teammates should always be able to view and respond to a conversation if a colleague tags them, regardless of who owns the conversation.Implementing this would give our managers time back, ensure a fair workload, and keep our cross-department collaboration smooth.  

    Jameson ThomasNew Participant

    API support for draft versioning of existing published articlesSubmitted

    Feature RequestExpose the Help Center article draft-versioning system via the Articles API. Specifically: the ability to save a pending revision of an existing published article without affecting the live version, and to publish that staged revision on demand — mirroring the draft-version behavior currently available in the UI editor.Current behaviorThe API supports creating new articles in a draft state before first publication. However, once an article is published, any PATCH to its content takes effect immediately on the live version. There is no API equivalent to the UI's "save draft version" workflow, where a revision can be prepared and held without going live.Desired behaviorPATCH /articles/{id} with a draft body parameter creates a pending revision without altering the live article The live article remains visible to customers until explicitly published A subsequent PATCH with state: published (or equivalent) promotes the staged revision to live Ideally, bulk-publish support for promoting multiple staged revisions simultaneouslyUse caseTeams managing large Help Centers frequently need to coordinate content updates with product releases — updating terminology, adding new sections, or revising instructions to match UI changes that haven't shipped yet. With the current API, the only options are:Execute all changes live on release night, accepting the risk of a partially-updated knowledge base if something fails mid-run Apply changes manually through the UI editor in advance to use the draft-version feature, then publish from the UI on release night — which negates the scalability benefit of the API for large update batchesNeither option is well-suited to teams managing hundreds of articles across a timed release. Draft versioning via the API would allow content teams to prepare, review, and stage updates programmatically in advance, then publish atomically at go-live — the same workflow the UI already supports, extended to API-driven automation.Priority signalThis gap is most acutely felt during major product releases that require coordinated, cross-KB content updates. The inability to stage changes via API forces a choice between manual UI work at scale or live execution risk on release night. For teams using the API specifically to reduce manual overhead, this is a meaningful limitation.