Common Issues
The problems teams actually hit when setting up and running an integration — grouped by integration, with the symptom, the cause, and the fix.
This page collects the failures teams actually run into. Each entry names the symptom you would see, what actually causes it, and what clears it.
Issues are grouped by integration, so the section you want is the system you are connecting.
Sort it in two questions first
Nearly every integration problem lands in one of two buckets, and telling them apart saves the most time:
Does it affect one user, or everyone?
Everyone at once points at organization-level configuration — the instance is unreachable, validation failed, or the integration is disabled. No individual reconnection will help until that is fixed.
One user while the team is fine points at that person's own connection: not connected, expired, or credentials rejected.
What do the two statuses say?
Every integration reports status at both levels. Read the organization's status in Dashboard → Integrations, and the user's in Dashboard → Settings → Integrations. The mismatch between them usually names the problem before any error message does.
WeSuite
Setup steps and field reference for this integration live in the WeSuite integration guide.
Validation fails during organization setup
Symptom. The setup wizard will not advance past Validate Connection, and the
organization status reads validation_failed.
Work through the causes in this order:
| Check | Why it fails |
|---|---|
| The URL has a scheme | Both URLs are parsed before the wizard advances; wesuite.company.com is rejected, https://wesuite.company.com/api is accepted |
| The API URL is the API, not the front end | The API URL usually ends in /api. Pointing it at QuoteAnywhere reaches a real server that cannot answer the validation call |
| The API URL is reachable from outside your network | Validation contacts the API and nothing else. WeSuite is typically on-premises, so if the API is only reachable inside your network, Selena cannot validate it — a firewall or allowlist question for whoever runs the instance. The QuoteAnywhere URL is not contacted here |
| The admin credentials are current | They are checked live against WeSuite. A rotated or disabled admin password fails here |
| The TLS certificate chain is complete | An incomplete chain is refused before credentials are checked, so correct ones still fail — see certificate chain |
The admin username and password in this step are used for validation only and are not what individual users authenticate with later. Every user still connects with their own account.
"Failed to authenticate with WeSuite" with a valid admin account
Symptom. Validation fails with Failed to authenticate with WeSuite, even though the admin username and password are correct and work when signing in to WeSuite directly. Server-side logs show a TLS error — most often:
UNABLE_TO_VERIFY_LEAF_SIGNATURECause. The WeSuite API's HTTPS certificate chain is incomplete. The server is sending its own (leaf) certificate but not the intermediate certificate(s) that link it to a trusted root, so Selena cannot verify it and the connection is refused before any credentials are ever checked.
The reason this is easy to misread: browsers frequently hide the problem. They cache intermediates from other sites and can fetch a missing one on the fly, so the API URL can look perfectly healthy in a browser and still fail from Selena, which validates the chain strictly and will not fill in what the server omits.
Failed to authenticate with WeSuite is a catch-all. The wizard shows the same message for a wrong password, an unreachable host, and a TLS failure — the specific reason is not surfaced there. The log line is what tells them apart, so if the credentials are known-good, suspect the certificate before the account.
Confirm it. Check what the server actually sends, from outside your network:
openssl s_client -connect wesuite.yourcompany.com:443 \
-servername wesuite.yourcompany.com -showcerts </dev/nullA correctly configured host returns the leaf and every intermediate above it. The chain is incomplete if only one certificate comes back, or if the output ends in:
Verify return code: 21 (unable to verify the first certificate)Fix. Install the CA's full intermediate bundle on whatever terminates TLS for the WeSuite API — IIS on the WeSuite host itself, or the reverse proxy or load balancer in front of it:
| Step | Detail |
|---|---|
| Get the bundle | Your certificate authority publishes it; it usually ships alongside the certificate as a .p7b or a chain .pem |
| Install it | On IIS, the intermediates belong in the machine's Intermediate Certification Authorities store. On a proxy, append them to the certificate file |
| Order matters | Leaf first, then each intermediate up the chain. The root is not needed — it is already trusted |
| Re-check | Re-run the openssl command and confirm the full chain comes back, then use Validate Connection again |
A self-signed certificate, or one issued by a private internal CA, fails the same way and for the same reason — Selena trusts publicly recognized authorities, and there is no option to skip verification. The WeSuite API needs a certificate from a public CA to be reachable from Selena.
This blocks more than setup. Every WeSuite call — including each user connecting their own account — goes through the same TLS validation, so an incomplete chain stops the whole team, not only the admin running the wizard.
"Data sync unavailable" during setup
Symptom. The data sync checkbox in step 2 of the wizard is greyed out, with a note about a missing permission — or the sync panel shows Data sync unavailable after setup.
Cause. The WeSuite admin account used for validation does not hold the ProgramOptions permission, which is what allows Selena to provision the data-sync API key.
Fix. Nothing is broken and setup is not blocked — the rest of the integration works, and every agent workflow that reads or writes as a user is unaffected. Have that permission granted in WeSuite, then enable sync later from the integration's settings. Validating with an admin account that already holds the permission also works.
Everyone in the organization is blocked at once
Symptom. No one can use WeSuite workflows, regardless of their personal connection
status. Users may see their own status as not_available.
Cause. The organization-level configuration is not in a working state. not_available
on a user specifically means the organization has never been configured.
Fix. Check the organization status in Dashboard → Integrations → WeSuite before touching any individual account:
| Organization status | What it means | What to do |
|---|---|---|
not_configured | No admin has set the integration up | Run organization setup |
pending_validation | Validation is running | Wait, then reload |
validation_failed | The instance could not be validated | See validation fails |
connection_error | It worked before and has stopped | See connection error |
configured | The organization is fine — the problem is per-user | See user not connected |
A previously working integration reports a connection error
Symptom. The organization status moves from configured to connection_error, with
no configuration change on the Selena side.
Cause. Selena can no longer reach or authenticate against the instance it validated. In practice that is one of three things: the WeSuite instance moved or changed URL, it is temporarily unreachable, or the admin account used at validation was disabled or had its password rotated.
Fix. Use Re-validate Connection on the integration page and enter current admin credentials. Re-validating is what clears the state — it does not disturb user connections, and no one has to reconnect.
One user gets 403 User not connected to WeSuite
Symptom. One person's requests fail with a 403 naming the connection, while everyone
else works normally and the organization status reads configured.
Cause. That user has no personal WeSuite connection. The organization being configured does not connect anybody — each user authenticates individually.
Fix. The user connects their own WeSuite account in Dashboard → Settings → Integrations → WeSuite.
A 403 that names an organization rather than a connection is a different problem:
the request's token carries no active organization, which is not specific to any
integration.
A user's connection stops working
Symptom. Someone who was working fine starts failing. Their status reads
token_expired or auth_error.
| User status | Cause | Fix |
|---|---|---|
token_expired | The WeSuite session behind their connection has aged out | Refresh on their connection; reconnect if the refresh fails |
auth_error | WeSuite rejected the stored credentials — usually a password change or a disabled account | Reconnect with current credentials |
Because connections are per user, one person's expired session never affects anyone else. That is also the tell: a single user failing while the team is fine is almost always one of these two.
A part exists in WeSuite but Selena cannot find it
Symptom. An agent reports no match for a part you can see in WeSuite, or a BOM row lands as unmatched.
Cause. Parts search spans what your organization has configured: your WeSuite catalog, company favorites, and accounting-system sources. A part that lives only in a source that is not configured is not visible to search.
Fix. Confirm which source the part actually lives in. If it is in a source your organization has not configured, the fix is in WeSuite, not in Selena. For a one-off, adding it as a one-time custom part puts it on the estimate without waiting on catalog work.
Search returning several candidates instead of one is not a failure. Selena returns the candidates whenever a part is resolved from text rather than an exact part number — including when there is a single match — so a wrong item cannot be silently priced into a live quote.
An estimate may have been created twice
Symptom. Creating an estimate appears to fail, or its outcome is unclear, and you are unsure whether to ask again.
Cause. WeSuite's create-estimate call carries no idempotency key, so a retry creates a second estimate rather than being ignored. Estimate notes have the same exposure. Selena never retries a failed write on its own, which is exactly so this decision stays with you.
Fix. Check WeSuite before asking again — it may have succeeded and failed only to report. Adding line items is safer: those calls carry a duplicate guard, so a repeat comes back as ignored rather than writing twice.
Data sync shows "Action required"
Symptom. The data sync panel shows Action required, saying the API key Selena uses was revoked or expired in WeSuite. Sync has stopped.
Cause. The data-sync API key is held in WeSuite and can be revoked or expire there, independently of the rest of the integration.
Fix. Click Reconnect in that panel to issue a new key and resume the schedule. Agent workflows are unaffected while this is outstanding — they read and write as the connected user and do not use the sync key.
Sync status reads "Failed"
Symptom. The sync badge shows Failed, and Last synced is older than the configured frequency.
Cause. A sync run did not complete — most often because the instance was unreachable mid-run.
Fix. A failed organization is picked up again on the next scheduled run, so a single
failure usually clears itself. If it stays failed, check the organization status for
connection_error; if the panel is asking you to
reconnect, that is key rotation instead.
Still stuck?
Ask in the Selena AI Discord. The three facts that narrow a problem down fastest are:
- The workflow you were in when it failed
- Whether it affects one user or everyone in the organization
- The record involved — the estimate, customer, or file