Hello im working n8n cloud enterprise , to integrate a box application into n8n. A previous user had already integrated their box application into n8n, but we would like to use one singular application for all users. If we were to disable the previous users box application and integrate a new one how would this affect their workflows. What would be the best way of going about a transition in integration of the applications?
@raliche
I recommend create the new central Box app and credential first, update/test all workflows to use that new credential, and only disable the old Box app after confirming nothing still depends on it.
Hi @Miliaga, Repeated answers don’t count. 
Don’t turn the old Box app off yet. Treat this like a credential migration with a rollback window: set up the new central Box app + credential first, pick one low-risk workflow as a canary, then move workflows in batches while the old app stays enabled until run history confirms nothing is still calling it. The thing I’d check most carefully is whether any workflows are using per-user saved credentials or shared folders with different Box permission scopes; that is where these migrations usually look fine in the editor and then fail on scheduled runs.
If this is tied to enterprise users, I’d write the migration map before touching production: workflow list, credential owner, Box scopes, test folder/file operation, batch order, rollback owner. I can do that as a focused migration plan/review so you are not testing it live on every workflow. My oimrqs ops contact link is in my n8n profile if you want help scoping it.
“Treat this like a credential migration with a rollback window: set up the new central Box app + credential first, pick one low-risk workflow as a canary, then move workflows in batches while the old app stays enabled until run history confirms nothing is still calling it”
How would you suggest checking where the workflow is being ran ? currently i dont have access to this and even when it comes to testing by creating a workflow and than connecting to box the exchange of credentials (client id and secret) is happening on the backend and doesnt ask for these credentials. Once logged in any user would have access to the box application however we are unsure which box application is being used.
I would first identify the n8n credential being used by each Box node, rather than trying to infer it from the login screen. the node uses OAuth2 credentials, and on Enterprise/Cloud the practical way to audit this is through the workflows/projects and credentials access you have as an owner/admin. Check each workflow using Box or Box Trigger, note the credential selected on those nodes, then migrate those workflows to the new central Box credential in batches. Keep the old Box app enabled until execution history confirms no workflows are still using the old credential.
to see which credential each workflow is using, go to Settings → Credentials as admin, you’ll see all Box credentials listed there. then open each Box node in your workflows and the credential name is shown directly in the node config.
also worth checking how many Box credentials exist total — if there’s only one, all workflows are already sharing it and your migration is simpler than you think.
just don’t disable the old app until you’ve done at least one scheduled test run on the new credential, not just manual. scheduled runs sometimes use cached tokens and fail silently.
@raliche I would not try to identify the Box app from the OAuth login screen. That only proves the user can authorize; it does not tell you which saved n8n credential/workflow is still tied to the old app.
The reliable check is an inventory from n8n first:
- Ask an n8n owner/admin to pull every workflow that contains a Box or Box Trigger node.
- For each one, record workflow name/id, project/owner, active yes/no, trigger type, Box node operation, selected credential name/id, and last successful execution time.
- In an exported workflow JSON, the useful part is the node
credentialsreference. You do not need the client secret for this. - Then compare each Box credential’s client ID with the Box Developer Console / Box admin connected-app record. That is where you confirm old app vs new app.
If you do not have access, the smallest safe ask to the admin is: send the non-secret workflow → Box credential map, plus the Box app client IDs, no client secrets.
With that table, you can pick a canary workflow and see which scheduled/webhook runs still depend on the old credential before disabling anything. If this is production, I would keep the first step as a migration map/review: workflow count, credential count, trigger types, last execution timestamps, and target Box app scopes. From that I can tell you the cutover order without touching secrets or Box files.