App tokens versus user-bound tokens, scoping, rotation, and offboarding.
Each integration Synthelio offers needs a credential, and they are not all the same kind of thing. Some are scoped app tokens, some are OAuth grants, and one is a user login. The difference matters for how you set them up and what happens when somebody leaves.
App-level credentials are issued to an application rather than to a person. HubSpot legacy app tokens, Dynamics client secrets, and the Slack and QuickBooks OAuth grants work this way. They survive staff changes and can be scoped narrowly to just what the integration needs.
User-bound credentials act as a specific person and inherit that person's visibility. Pipedrive API tokens, Atlassian API tokens for Jira, and the Salesforce connected app flow all fall here.
User-bound credentials carry two risks worth planning around. The integration only sees what that person sees, so a token generated by someone with partial visibility produces a partial sync. And when that person leaves and their account is deactivated, the token dies with them and the integration stops.
The mitigation is the same in every case: generate user-bound credentials from an account that will outlast any individual's tenure and has the visibility the integration actually needs.
Where a provider lets you choose permissions, give the integration the minimum that works.
The clearest example is HubSpot. The three read scopes are all that is required for the pipeline sync. The write scope is only needed if you turn on pushing SOW amounts back to deals. If you are not using that feature, do not grant it, and if you are, know that it is the only thing Synthelio writes to your CRM.
For Dynamics, delegated user impersonation and application permissions are different postures with different blast radiuses. Pick deliberately rather than by whichever appears first in the documentation.
Worth being direct about, because a security reviewer will spot it and it is better coming from you.
The Salesforce connection uses the OAuth username-password flow, which means storing a username together with a password and security token concatenated, in addition to the connected app's consumer key and secret. It also requires enabling username-password flows at the org level and relaxing IP restrictions on the connected app.
That is a heavier credential than any of the other integrations require, and it is a Salesforce flow characteristic rather than something Synthelio chose. If your security posture does not permit it, that is a legitimate position, and the practical answer today is to hold off on the Salesforce connection rather than to weaken your org settings.
If you do proceed, use a dedicated integration user with exactly the object access the sync needs, not an administrator account and not a real person's login.
Credentials expire, get rotated, and occasionally need killing quickly. Three habits cover most of it:
Run this list, because it is where integrations quietly break or quietly stay open:
The order matters. Once their Atlassian account is gone, the token is unrecoverable and the Jira sync stops with no obvious explanation.
Worth separating, because it is the one place where no stored credential exists.
The MCP connector uses per-user OAuth. There is no service account, no shared secret, and no pooled access. Every request runs as the person who authorized it, under their own permissions, and deactivating them ends it immediately.
Tell us what you need. We will point you to the answer or write the article.
