When you say the users ‘update’ the report - I am guessing/assuming you mean your stored procedure is executed and that stored procedure builds/updates a table in some database.
A report should only read data from a source system - it should never (in my opinion) update data in a source system as part of generating the report.
If that is what you are doing you need to reconsider how you are producing the data for this report. If the code you are using to generate this data just takes too long for users to wait - there are many other options, the last of which would be creating a table specifically for that report.
For example - you could easily create the report to run a query that takes even up to 30+ minutes to execute - wrap that in a stored procedure and use that stored procedure for the report. In SSRS - you then create a schedule to generate a snapshot on a scheduled basis, set it up so the report is rendered from the snapshot - then create a schedule based on the snapshot being updated that sends out notifications.
Another option - create a separate process scheduled in SQL Server Agent to build what you need (a table of qualifying items with internal values (PK/FK) only). Then you build a procedure that uses these tables for the actual report…
The key to your issue is making sure your report is rendered from the snapshot - and that you generate the snapshots on a scheduled basis.