Lost Data?

I have a client who recently discovered that they had an inbound integration overwriting some important opportunity data in Salesforce.  Unfortunately, the field that was being overwritten was not a field that had tracking turned on as they had reached their limit of 20 fields.

Salesforce has put together a nice checklist of things you can do to try to recover lost or deleted data.  For my client, the suggestions weren't options to consider because the data updates were incremental over a long period of time.

However, we didn't give up, and were able to recover some of the data from workflow emails!  The attribute that they thought they had lost was part of the Won email that was sent out and because the administrator was copied on these emails, we just had to figure out a way to extract the data we wanted to recover.  Turns out if you can get your email into Outlook, Access has a way to import email messages.  Once the emails are in Access, a few little queries can fetch the data you might need.  For us, we just needed the link to the opportunity and a value from the email template.  Once the query fetched the data we wanted, a little scrubbing in Excel cleansed the rows for import.

TL;DR: you might be able to recover lost data from your workflow emails!

Workflow and User Permissions

Q: Do workflow rules run as the user or do they run as the system?  For example, if you had a sales team associate update an opportunity and there was a workflow that fired on any opportunity edit, would the workflow update a field that the user did not have profile (or permission set) permission to update?

Q: If the workflow action reassigned ownership to another user, would it execute the ownership change despite the user's system permission of Transfer Records as false?

Q: If the workflow action changed the record type to a value, would it change the record type if the user's profile did not have access to the specific record type value?

***

My initial reaction was that workflow would run as the logged in user and would obey the user's profile and permission sets.  However upon testing, what I found was that workflow runs as the system and does not honor the user's profile or permission.  So, for the 3 questions above:

1. Workflows run as the system and would update a field that the user did not have profile/permission set access to update
2. Workflows will execute ownership changes on behalf of users who do not have permission to directly change the ownership
3. Workflows will change record types in spite of profile-specified record type access.