Here's one possibility that comes to mind if you were to write a trigger on Quote
. There's no Quote History object, but there is the Quote PDF's
related list that may have some kind of impact on the LastReferencedDate
. Quote
has two fields that might be of use: LastReferencedDate
and LastViewedDate
. LastReferencedDate
would be the time your button accesses the Quote data when it prints the PDF.
The hitch to all this will be that I don't know if the LastReferenceDate
will be updated again after the PDF document save happens or only when the data is accessed to generate the PDF. You'll need to test this behavior to see.
If your trigger detected a change in the LastReferencedDate
, then ran a query that also found a new QuoteDocument
for the same QuoteId
record with a similar CreatedDate
(you'd need to be loose with your criteria here as referenced vs save could be substantial), that could be an indicator that you have new QuoteDocument for that record.
To do this properly, you'd likely need to have a custom object that holds your previous values (think of it as a trigger.old) for QuoteDocuments you query that stores it by QuoteId. That would be the only way I can think of to ensure you knew this was a new document since the last time the trigger had fired.
You'd also want to compare other fields on Quote to make certain the trigger wasn't being fired for other reasons before deciding whether to run your query or on which records to run it. This is one general approach to trying to solve the problem you describe using a trigger that comes to mind at the moment.
renderAs="PDF"
. There's no DML that occurs that you could key off of when it's opened. Unless the page is saved, there's no event to trigger anything of off. And once you did, I don't believe that Quote would be updated since the PDF doesn't write to the Quote object. It's simply a document. It would entirely be a matter of how that document is saved that would present the opportunity to trigger further action.