From doing a search outside of ALMA, I have an MMS_id for a record I want to look at. (E.g. 9913920213502836 )

I want to be able to share this record page with a colleague, or store a pointer to the record in a document or spreadsheet.

The most useful approach would be to use a URL, where I could display the MMSid as the text, while pointing to the record as the URL ( e.g. www.myalmadomain/mng/action/showrecord.do?mms_id=9913920213502836 )

Because of how the page is built, there doesn’t appear to be a single url I can use to resolve the record page - I can only see the ‘parent’ URL: https://nlnz-a.alma.exlibrisgroup.com/mng/action/home.do?mode=ajax#

Alma ticket case #00668253 refers - closed as enhancement request:

"Unfortunately, differently from Primo, Alma does not provide like a permanent link or direct link to a record. Users need to authenticate to Alma, then search MMS ID and etc."

We have electronic services that comprise portfolios from multiple publishers, and the portfolio URLs link to the publishers' websites rather than a common platform. Currently, this means that Alma can only link to the journal level, unless we edit each individual portfolio to use a Dynamic URL. However, because the structure of the URLs after the domain is consistent, we would be able to apply a single, article-level Dynamic URL at the Service level if Alma had a parser parameter we could use in place of the domain. Here is the URL format with a couple of examples:

http://{domain}/content/{rft.volume}/{rft.issue}/{rft.spage}
http://www.eje-online.org/content/176/3/349
http://jcs.biologists.org/content/130/8/1365

Because there is currently no {domain} parameter, we're forced to make changes on every portfolio. We'd love to be able to apply this at the Service level instead.

At present if users follow a link from one of our website or our VLE to an item with more than one content provider or a Public Note it takes them to an Alma landing page for the uresolver, which opens in a new window or tab.
The <title> of the Alma uresolver tab or window shows as 'Home'. If the user has several tabs open the word 'Home' is not likely to help them identify the one that contains the links to the item they were trying to access. It would be much more helpful if the browser tab or window could display the title of the item, as it does in Primo (classic UI) if you open the 'View it' tab in a new window/tab.
For example, Alma uresolver: https://eu01.alma.exlibrisgroup.com/view/uresolver/44OPN_INST/openurl?&u.ignore_date_coverage=true&rfr_id=info:sid/primo.exlibrisgroup.com&svc_dat=viewit&u.ignore_af_filter=true&internalAccess=true&isInNewWindow=true&rft.mms_id=9938796810102316
Primo View it or Details: http://pmt-eu.hosted.exlibrisgroup.com/44OPN_VU1:EVERYTHING:44OPN_ALMA_DS6181135030002316

Sometimes the Alma openurl resolver can't locate an item, but you can find it in the CDI, so could the openurl resolver search the CDI by title + authors for possible matches? Perhaps present any results as suggestions, a bit like bX recommendations, so as not to raise expectations that the correct document has been found.

Here's an example. JSTOR has a record for a paper that was published in print in SAE Transactions, ISSN 0096-736X, 2001, Vol.110, p.86-92
https://www.jstor.org/stable/44724287

But the paper is published online as SAE Technical Paper 2001-01-0233, ISSN 0148-7191
https://www.sae.org/publications/technical-papers/content/2001-01-0233/

It is available in SAE Mobilus and there is a CDI record with a link in record, TNcdisaetechnicalpapers2001010233

So the Alma link resolver has no hope of finding that from the openurl from JSTOR, but if it could search the CDI by title and authors, that would lead to the full text.

While this would be helpful across the board, specifically with ProQuest's ownership of ExLibris it seems a logical step to add a link resolver API to increase the efficacy of the services page.

Specifically request a Proquest Link Resolver API Plugin that would allow Alma to do a pre-check to ProQuest to see if full text is available. If the pre-check API query returns 0 matches, then the Full Text Service would be suppressed and the user would see 'No Full Text' on the Services Page. This would address certain linking issues where the services page recognizes full text is available but is unable to resolve the linking b/c of content provider metadata mismatch.