Who would benefit? |
Everyone who uses inriver to export product data |
What impact would it make? |
It would allow clients and implementation partners more independence to troubleshoot export errors without the need to contact inriver support every time one fails |
How should it work? |
I think it should be implemented in stages. The initial stage should be a report containing the SYS ID of the entity that caused the export to fail. After this first stage is implemented, we can begin making a list of the common use cases that cause an export to fail. When we have this list, we can revise the error output to be more robust. |
Why is it needed? |
We have seen bad data cause client exports to fail. The current troubleshooting approach is to subdivide the initial query into smaller and smaller chunks until the entity with an issue is identified. If the export covers a large number of attributes, this process can take a while. |
Additional feedback, background or context: Support ticket submitted explaining the use case from ELC and inquiring about the nature of export error logging in CC: https://community.inriver.com/hc/en-us/requests/63576