Troubleshooting And Notes

Common things to verify

If shared files are not behaving as expected, verify:

• The shared-file connection test succeeds.
• The correct site and library were selected.
• The root folder is correct.
• Each active workflow has its own Download, In Review, and Archive folders.
• The scheduled scan is active, not on hold.
• New files are being placed in the Download folder, not one of the later-stage folders.
• Automatic movement and optional cleanup settings match the process your team expects.

Operational gaps worth knowing

• There is no visible warning when the saved connection secret is close to expiring. The connection can stop working suddenly unless someone tracks that expiration outside the system.
• The scheduled shared-file scan is created in an on-hold state by default. A user must activate it before any automatic pickup happens.
• If processing has already created the final business record, later shared-file actions such as moving to Archive or deleting the source file can still fail separately. This can leave the final result complete while the shared folder location is out of sync.
• There is no clear user-facing recovery flow for files that fail during later folder moves or cleanup. The implementation writes failures to the processing log instead.
• If automatic movement is enabled, a file moves into In Review when processing starts. If processing later fails, the implementation does not automatically move that file back to the incoming folder.
• The shared-files feature works by scanning the Download folder for each active workflow. There is no separate user-facing action for an immediate one-time scan from the setup page.