Feature request

The current Display Address is not very valuable for me, as they only show the host/user and you can have a lot of Locations with the same host/user. In Link 2 it was the Folder Name, but you did not know of the user. Slightly better, but not perf...

In the Tracking Field setup page, we need to have explanatory texts (tooltips) for each of the fields presented: Name Document type XPath Show in search preview Group Type Display name Is required RegEx RegEx error Information Default value Order ...

The idea is that - based on an XML-structure - Link should generate a strongly typed API that can be used for message receival.

Will there be a separate menu for Conversion tables, so you don't have to enter overview from a specific partner?

It would be great if we had a D365 specific HTTP connector. I understand that by modifying the existing HTTP connector the same function could be achieved, but from a user perspective it is more intuitive to have a specific connector. Also if in t...

It would be very helpful to see some more information from the itinerarystep logging. 1) The naming of the file could include information about ie the xsl that is executed in stead of only the step-name : system-itinerary-xsltransform.txt 2) In th...

In the original design of proxy partners, the related partners had to be present before importing the proxy partner. This is a bit awkward as there is no easy way to see if this is a problem before importing, as you can mix and match proxy partner...

This is two ideas that are somewhat connected. The first one is easy to implement: When I import a Distribution from Test into Prod, the import fails when the location names are different. This makes sense, however there should be an option to ove...

Deleting any of these objects throws a database reference exception in the UI. It would be nice to be able to soft delete these objects because as it is now, it is very hard to get rid of these when they have been used for processing documents.

HTTP components in LINK are able to do PUT, POST and PATCH. In some cases we at least need to support GET but DELETE would also be nice to have. HEAD, OPTIONS, TRACE and CONNECT, I don't see much use for but unless the underlying implementation is...