Imagine a user viewing a table in a (web) application which has some input capable cells:
download bmml source – Wireframes created with Balsamiq Mockups
If they click "Export to Excel" should the CSV / XLS they download reflect the current edits they've made -- even if they have not saved/submitted their edits?
When the user takes any action, including export, it should be relative to the current state of the data in front of them. If any other behavior is implemented the button/menu should clearly indicate that fact. The user chose the action based on what they are seeing, so to act on any prior version of the data instead would be misleading, not withstanding undo/redo type actions.
The data exported should be what the user currently sees. That is, it should represent any un-saved edits.
Here are a few File dialogs showing both Save and Export options.
In each case the Export action takes action on the current data being displayed.
USE CASE - in an image editor you may wish to make a small change to the master Photoshop (or whatever) file, export it to a PNG file and then exit. The change is not desired to remain in the master file.
Notice that both Save and Export in these cases are on the same level. They take the same action, just in a slightly different way. In fact, "Export" is commonly just a different way to say "Save As" and selecting a different file format.
Since your table data can both be "Saved" and "Exported", both actions should be on the same action level. Don't put Export someplace special - put it right next to Save. If your "Save" option is a multi-step process (e.g., it asks for a filename), you could include a file format option and allow the user to "Save to Excel" instead.
Interviewing your users and finding their mental model of "Save" vs. "Export", as well as your default format vs. an Excel format, might help you find the most applicable solution for your user base.
