← Back to docs

Live support and suggestions

Live support and suggestions

Tools provides live support for signed-in users and guests, plus a public suggestion board for product ideas and feedback.

Signed-in support

Open /me/support to start a conversation and follow earlier conversations. Replies appear on the page without a full reload while the page is open. A signed-in user can only read and write their own conversations.

Support staff can take over and answer the same conversation from the administrator support workspace. Administrators can also start a support conversation manually for a Tools user.

Guest support

Open /support/live if you are not signed in. Tools creates a private browser support session and uses it to keep your guest conversations separate from other visitors. The guest session is required to continue reading or replying to a conversation; knowing a conversation reference alone is not enough.

Authorized support staff can see limited session context needed to identify and troubleshoot the guest conversation, including first/last visit time, browser information, the related page and network address. Tools does not copy passwords, authentication tokens, cookies or request payloads into the support record.

Slack support reporting

Support chat activity is also copied to a dedicated private support channel in Slack so the support team can follow conversations. This includes chat text and safe conversation context. Operational Slack delivery failures do not block the conversation itself and are reported separately to Tools operations.

Public suggestion board

Open /suggestions to browse public feedback or publish a new suggestion. The form has two independent dropdowns:

  • Service - derived directly from the current /services catalogue, plus a general Tools platform choice. A service card that is added, renamed or removed from the catalogue automatically changes the suggestion choices as well.
  • Feedback type - new feature, improvement, good/works well, bad/works poorly, integration, problem/bug or other feedback.

New submissions explicitly acknowledge that the selected service, feedback type, title and description are public. A relevant URL is private by default and is published only when the submitter selects the public-URL option.

Submitter identity is separate from the public suggestion. Tools does not show the linked user account, optional guest name/email, private support replies or support audit data on public suggestion pages. Historical suggestions created before this public-board workflow remain private until an authorized support administrator explicitly publishes them.

Possible statuses are new, reviewing, planned, implemented, rejected and closed.

Administrator management

Authorized administrators can open Suggestions & feedback directly from /admin. When an administrator with support.manage is already browsing the public /suggestions list or a public suggestion detail page, status can also be changed there with the same protected AJAX action, and an Administer link opens the matching administrator detail directly. Normal visitors never receive these controls. The administrator detail still provides publication controls, private support replies and GitHub handoff. Administrators can permanently delete unwanted or test suggestions after confirmation; private suggestion replies are removed with the suggestion, audit history is retained, and an already linked GitHub issue is left unchanged.

Copilot and GPT implementation instructions

Every public suggestion has a copyable implementation instruction generated deterministically from its public fields and the permanent ToolsAPI development rules. The instruction identifies the affected service, feedback type, requested change, testing expectations, GUI/API/access-control/audit checks, documentation requirements and the rule that first-party Tools API URLs remain unversioned.

Private contact data and private support replies are never added to the generated instruction.

GitHub development tickets

Authorized support administrators can search for, link or create a GitHub issue from a suggestion. Suggestion tickets are restricted to Tornevall/toolsApi; one configured fine-grained GitHub token with Issues read/write access is reused for issue search, exact issue validation, linking and creation. The token is encrypted at rest and is never rendered back into the browser.

Before creating a new issue, Tools searches the configured repository server-side. If matching issues exist, the administrator must review them and explicitly confirm that a new issue should still be created, or link one of the matches instead. Pull requests and issue URLs from other repositories are rejected. A suggestion that is already linked keeps that issue instead of creating another one.

The GitHub ticket title can be different from the public suggestion title. An administrator can enter the ticket title manually or ask the existing Tools AI infrastructure for title proposals. AI proposals use only public suggestion fields and the generated implementation instruction, and nothing is saved until the administrator explicitly chooses and saves a title.

New issue creation remains server-side and requires the suggestion to be public and reviewed. The created issue contains only public suggestion context and the generated implementation instruction. Search/link/create operations keep the existing audit and always-on operational diagnostics contract without exposing credentials or private support data.

Once an issue is linked, public readers only see that development handoff is in progress. The private Tornevall/toolsApi issue number and URL remain available to authorized administrators.