Support · troubleshootingFind the boundary. Fix the cause.
Use the first failed step to narrow the problem. Don’t add broad permissions just to make an error disappear.
AWSStack failed or rolled back+
Open CloudFormation Events and find the first CREATE_FAILED resource. Check installer IAM/Lambda rights, named-IAM acknowledgement, SCPs, and an existing failed stack. For ROLLBACK_COMPLETE, delete only that failed stack and obtain a fresh customer-specific link.
Open the relevant guide →AWSStack complete, integration disconnected+
Inspect OnboardingStatus and the registration error. Compare AccountId and RoleArn with the intended account. Refresh Integrations. Share the stack ID and redacted first error, never the ConnectToken.
Open the relevant guide →AWSOIDC or AssumeRoleWithWebIdentity denied+
Verify the account-local provider ARN, audience, current approved workspace subject, and effective policy controls. Do not remove trust conditions or use a wildcard-only subject to bypass the failure.
Open the relevant guide →AWSOnly the management account has evidence+
A base stack does not deploy member roles. Compare your approved account list with installed roles and successful per-account collections. Review both sides of central-to-member trust.
Open the relevant guide →AWSThe engineer did not receive an invitation+
Confirm the Identity Center identity source and exact work email. An external IdP uses its own provisioning flow. An IAM console-only user does not receive an Identity Center invitation merely because its username is an email address.
Open the relevant guide →AzureAdmin consent is incomplete+
Use an authorized Entra consent administrator. Inspect Application (not Delegated) permissions and Granted status for Graph and Defender for Endpoint. Keep partial grant results; repair only the missing approvals.
Open the relevant guide →AzureSubscription roles are missing+
Check the signed-in administrator’s role-assignment rights at every approved scope. Entra administration alone does not confer Azure RBAC rights. Check deny assignments and inherited scope.
Open the relevant guide →AzureCallback or secure handoff failed+
Inspect the non-secret install manifest and callback error. The owner-readable credentials file remains in Cloud Shell and contains a secret: transfer it only through the approved secure channel. Do not attach it to support tickets.
Open the relevant guide →AzureConnected but no endpoint, Sentinel, or sign-in data+
Check the correct tenant/workspace, effective grants, product licensing, endpoint onboarding, diagnostic configuration, and time range. An API permission alone does not create telemetry.
Open the relevant guide →AzureApp credential expired+
Use the approved rotation workflow, verify a new collection, then retire the old credential. Never post the replacement secret in email or Slack.
Open the relevant guide →Bring a clean support bundle#
Include provider, onboarding method, non-secret account/tenant identifiers, approved scope, stack ID or app ID, first error with timestamp, and the non-secret install manifest. Redact tokens, secrets, authorization headers, customer log contents, and personal data not needed to investigate.
Do not “fix” these with AdministratorAccess#
An access-denied error can come from an account control policy, missing scope, wrong identity, role trust, missing consent, or a product with no configured data. More permissions in the wrong place do not solve an identity or registration problem.
Need a fresh connection link?#
Use the authenticated Transilience workspace or your authorized contact to obtain one. Do not recycle another customer’s Quick Create link, invent a callback URL, or paste a one-time connection token into this site.