You need to deeply think through the workflow around signing complex documents. Apple Mail now handles simple signatures directly within the email app. But this doesn't always work.

The workflow with Goodnotes (and all other apps, mostly because of sandboxing of common document types like PDF, which should not be sandboxed because they do no harm--but no one on the planet will convince Apple because Jobs didn't like file systems and no one at Apple can contest the memories of the infallible Jobs). Phew.

There are several problems specific to Goodnotes for this obvious and common business scenario:
1. Goodnotes doesn't support share sheets. So "open in..." or "Share" don't work from an email app (Mail, Outlook, etc) or from Preview (where most pdf's opened will open).
2. No. 1 requires a new workflow step: save the pdf somewhere.
3. Import the pdf so it can be signed with Goodnotes.
4. Again, a failing of no share sheet--most apps that can open or receive a pdf don't get shared to from Goodnotes.
5. Because of no. 4, export the flatted or editable PDF somewhere...
6. From the sender's email application, attach the pdf file from step 5.

This is a mess. I have 2 files that I must manage manually to in order to avoid retaining duplicate files.

How this should work:
1. From an email with an attached pdf file, open in Goodnotes.
2. Sign the document or make annotations, other comments as needed in Goodnotes.
3. "Email to..." as an explicit command in Goodnotes. Ideally there would be a reply to sender(s) option that would provide a bit of a shortcut by filling in to: field of the email app.

Under the hood, step 3 exports to a private place used by Goodnotes in the file system. As part of the email to (an alias for share via an email application) command this exported file--with a sensible name not autogenerated cryptic garbage--is attached to a blank new email. If "reply to" is enabled, then the to: field of the message has been filled out already. After hitting send, return to Goodnotes. Goodnotes itself is not responsible for displaying the new message or sending it: Goodnotes calls and passes the attachment to the email app. So, on return to Goodnotes (either automatically if the email application supports a callback) or because the user context switches to Goodnotes, there is a "Done" button or link in the dialog (or panel or page or view or whatever trendy UI mechanism is provided). Clicking done deletes the exported pdf from its hidden folder.

The hidden folder has to be accessible in the file system to handle inevitable failures in the workflow. The important thing here is that THERE IS NO REASON to retain the exported PDFs ever. The user has the signed (and/or marked up in other ways...) document as a native GoodNotes file in the Goodnotes icloud sandbox, visible in the Goodnotes UI. If the user wants to maintain duplicate PDF backups somewhere (Dropbox, ICloud Drive, OneDrive etc.) that is up to the user.

This reduces a 4 step process with 2 files to manage to a 2 step process with no files to manage.

Millennial developers might not consider this important, but it is a fundamental workflow for middle aged people with responsibilities. While the developer as user does lead to some good features, it is too limited a few. Go study (virtually--alas, Covid) real users. Developers are not always an ideal proxy for users.