When trusted organization relationships lapse

For the last few years NYU School of Medicine has signed a good number of faculty for ORCID trusted organization status (through which we maintain their publications and employement records on ORCID). In the natural order of things, some of these faculty have retired, moved on, or otherwise left NYU. Once they’ve gone, we no longer supply updates, but the trusted organization entry in faculty’s ORCID account settings remains in place. At present we have more than 200 faculty in this posture.

As we understand it, ex-faculty can revoke trusted organization status, but doing so will leave in place any publications or employment entries that NYU has added to their records and it’s not possible for the ORCID owner to edit these entries. Instead they must delete any such entries and then reenter them with whatever changes they believe are appropriate.

We would like to suggest that a better set up would be to automatically default such linked entries to be editable once the trusted organization status is revoked. That would more fully return control to the ORCID ID holder and be easier for most faculty to understand.

As NIH begins requiring ORCID ID in the new year, we anticipate a lot more faculty on ORCID. That will naturally lead to more ex-faculty in the mix, so this may be a good time to address this issue.

In any case, we’d be happy to hear from anyone who has model trusted org exit policies in place.

Stuart Spore
NYU School of Medicine

Hi Stuart,
Thanks so much for sharing this with the community. It is rare for a user to revoke permission from the ORCID-member such as NYU, but it does happen.

Only the source of the data can update it. This is part of ORCID’s Trust program, so we can build a registry of reliable data.


In your case, NYU asserted the employment data, so only NYU can update it with an end-date using the API. When the user revokes permission and wants to update the data, they have the option to either delete the data and re-enter it (this way they are the source of the data), or they can request NYU to send another permission request. The key is, only the source of the data can edit the data.

I will add your feedback to the Member Feedback Forum.

Please let us know if you have any questions.

Thank you,



I haven’t actually tried this, but what would make most sense to me from a UX point of view is for me as the owner of my ORCID record to be able to edit (rather than having to delete and re-enter) any details that form part of my record. The user themselves would be a special case in this regard, as I wouldn’t necessarily expect this for any other source. The issue of keeping the source correct could be handled by warning the user that the source will change from X to themselves when they save the record.

From a trust perspective this is no different to deleting and re-entering. From a UX perspective, it saves me having to re-type everything.

  • Guy

Hi Guy,
I think you make a strong case, I’ll share it with our UX and Product Team.

We’re working hard to make ORCID as effective as possible, community discourse helps us shape ORCID going forward. We really appreciate everyone’s feedback.

Thanks very much,


Just to clarify, if NYU (or in our case RTI) sends an end-date, then does permission to edit revert to the user? I couldn’t tell from your reply, what the impact of sending the end-date would be.