GIODE Protocol Failures get tracked in doc tracker

Hi,

Thank you for submitting this idea and for clearly calling out the gap around GIODE protocol failure visibility.

I understand that today, when outbound deliveries to GIODE-based direct trading partner connections fail, those failures are not surfaced in Doc Tracker, which limits customer self-service and forces dependency on support for basic status confirmation. Improving visibility here would help customers quickly determine whether a file failed at the protocol layer and take corrective action without opening a case.

From a product perspective, this enhancement aligns well with our broader goals around:

• End-to-end document lifecycle visibility

• Reduced support dependency for operational issues

• Consistent experience across protocols (AS2, X400, SFTP, GIODE, etc.)

Before we evaluate prioritization and scope, I’d like to clarify a few points to ensure we address the right customer need:

Questions

1. What specific failure scenarios should be exposed in Doc Tracker (e.g., connection failure, authentication error, partner unreachable, timeout)?

2. At which stage should the failure be reflected—initial send attempt only, or also retries and final failure status?

3. Do customers expect protocol-level error details (error codes/messages), or is a high-level failure reason sufficient?

4. Should this visibility be available to both customers and IBMers, or restricted by role?

5. Is there a particular customer volume or use case where this gap is causing the most operational impact today?

Once we have clarity on these points, we can assess feasibility, consistency with existing Inflight/Doc Tracker behavior, and potential roadmap placement.

Thanks again for raising this—visibility gaps like this are important signals for us as we continue to improve the platform.

Best regards,

Manoj Panda