Hub / Community

Where to Take What

This page is the routing: what to do with a connector bug, a question, a credential request, or a correction to something on this site.

Open now Connector issue trackers Open now membership@tsanet.org Open now GitHub Discussions

Routing

What Goes Where

If you want to…Go to
Report a bug or request a feature in a shipped connectorThat connector's issue tracker — see below
Get API credentials, a Beta account, or early accessmembership@tsanet.org
Arrange attachment enablement or a pilot instancemembership@tsanet.org
Tell us which connector to build nextWish List
Report something wrong or missing on this hubmembership@tsanet.org or Q&A
Ask the community how to do somethingQ&A
Show what you builtShow and tell
The short version: anything about a specific shipped connector goes to that connector's repository, where the maintainers and the history already are. Anything involving credentials or account changes goes to membership — a discussion thread is public, and credentials never should be. Everything else has a discussion category below.

Open today

Connector Issue Trackers

Each shipped connector is developed in the open, with a public issue tracker. This is the fastest route for anything specific: a bug, a behaviour that surprised you, a feature you need. The history is there too, so it is worth searching before filing — most surprising behaviours have been hit before.

ConnectorRepositoryUse it for
Salesforcetsanetgit/SFDC_AppManaged package, flows, Apex, LWC
Zendesktsanetgit/Zendesk_AppZAF app, ZIS bundle, field actions
Dynamicstsanetgit/MS_Power_AppSolution, plugins, Power Automate flows
Connect SDKtsanetgit/Connect_SDKJava client, console app, attachment receiver

Fin / Intercom, the Connect Gateway and ServiceNow have no public tracker — the first two are private repositories during early access, with access granted at onboarding, and the third is not built. Route all three through membership.

What makes a report easy to act on

Open now

Discussion Categories

Discussion runs in the tsanetgit organisation Discussions — one shared space for every TSANet repository, no separate accounts, no separate platform; a GitHub account is all it takes. The space is young: an empty category is an invitation, not a dead room, and early questions shape what the maintainers write next.

Q&Aanswerable

How do I do this? Auth, process forms, lifecycle transitions, webhook delivery. Answers can be marked, so the next person with the same question finds it.

Troubleshootinganswerable

Something is not working. Silent failures, signature mismatches, a sync that stopped. Distinct from Q&A because the useful answer is usually a diagnosis rather than an explanation.

Show and tell

What you built. Custom integrations, translation services, platform findings — including the unflattering ones, which are usually the most useful.

Wish List

Which connector should exist next, and what platform your team actually runs on. This is the one that most directly changes what gets built.

Membershipanswerable

Onboarding, pilot instances and early-access programmes. Anything involving actual credentials still goes to membership@tsanet.org — threads here are public.

Technology Committee

Ideas and proposals, in both directions. Changes you want to the API or the connectors: gaps, papercuts, and behaviour that surprised you enough to be worth changing rather than documenting. And requests for member input from the TSANet Technology Committee: connector roadmaps, feature proposals, and platform-wide behaviour questions such as note formatting and inline images.

Announcements

Maintainer posts only: connector releases, API changes, and the deprecation dates worth knowing about in advance.

Browse the discussions

This site

Corrections Are the Most Valuable Thing You Can Send

Much of what is on this hub was assembled from connector source, platform specifications and live probes rather than from a maintained document. That makes it useful and it also makes it fallible — and some of it is already known to be inconsistent at the source.

  • If a page contradicts what you observe in production, the page is more likely wrong than you are. Send it.
  • If two things on this hub disagree with each other, that is worth reporting even without knowing which is right.
  • If a documented gotcha no longer reproduces, that is just as useful — behaviours get fixed and pages go stale.
  • Every page states what it was verified against, and when. Start there when judging whether to trust something.
  • Where two sources genuinely disagree, pages say so rather than picking one quietly — the webhook retry policy is the current example.
  • Assessments carry evidence tags: documented means somebody read it, not that anybody saw it work.
Send a correction Or raise it in Q&A