Org links are links inside org files (though you can also make them work outside org). I have been using them to maintain a lot of buttons, or things that are functionally equivalent. The basic idea is to define a link type and setup functions for what happens when you click on it, and (optionally) what happens on org export (depending on the export backend). To know what they are capable of, look at Malabarba's series on org links. Also Cheong Yiufung has a post on few hidden org link features here.
A lot of basic external link types are mentioned in the docs. Special helpful is
the elisp one which lets you invoke arbitrary elisp. The bookmarks you save via
org capture also are just org-links.
If your org files have links that have a usable export view, they get a whole lot better. For example, I keep an org file with search based playlists for my music player. Clicking fires the playlist and exporting lays out the items from that list along with the youtube embed trick from Malabarba.
One annoyance with links is that the export function looses buffer context (the
(point) isn't at link's position), making it harder to export links that
disambiguate based on surrounding information. At a certain point in time, I
used to have github issue links that looked like [[gh:n]] where n defines the
issue number. The idea was to look up repository path in the current headline's
drawer before interpreting the link. This works with follow function but not in
exports.
A workaround is to probably just use a snippet which looks up the property before creating the link. Since this repeats the url, it hurts portability of links (though I don't know why I would want to move these links around). A better way might be to have the snippet prepend a uuid and the export can then pick up the position.