I'm trying to get a rudimentary understanding and example use case for the use of the targetLocation parameter in a!recordLink(). I've read the documentation but I still can't picture a use case. I've played with it in terms of configuration. I'm just not sure why someone would need it. Has anyone every used this parameter before? What was it used tor?
Discussion posts and replies are publicly visible
Hello Kim Day
Usually the record link will redirect with the url as suite/tempo/records/item/someadditional value
ex: .com/suite/design/koOew33rfs3Oew33rfs3Oew33rfs3
when used the targetLocation, you can define the site page that it should use as the reference/url site!siteName.pages.pageName
ex: .com/suite/sites/itam/group/master-details/page/soandso-detail/record/kOew33rfs3
[edit: the following is true for the "dashboard" parameter, my bad. see my update below.]
Simply put - if I have an interface where I'm linking to a particular record, but the more relevant Record View (from the current interace) is some View other than the default "summary" view for records I'm linking to, this allows me to now send users straight to that.
For instance if I'm on a site used by Workforce Documentation managers, and i have a grid of personnel (record type) with documentation uploaded to their personal in-Appian folders, this would let me link straight to their "/Documents" views (presuming we have a "/Documents" view set up with, let's say, a grid of all that user's files and so-forth), instead of forcing the user to click to that personnel's Summary page then manually click the "Documents" tab from there.
This is perfect, exactly what I needed. Thanks!
Actually sorry I was incorrect. What I wrote above is in referrence to the "Dashboard" parameter (which i'm more used to). Sorry for the misinfo.
The TargetLocation parameter can apparently control what SITE tab the opened record link "opens" in. This can be useful for controlling the exact record link behavior, as pertains to their location within a site (or cross-site, i believe). Before we were basically just stuck with taking the site "location" as wherever the user happens to click the link from, which opened up some weird (and uncontrollable) corner cases.