Alerts and Notifications

There are various different ways you can be alerted with notifications about the progress of GRAX jobs, as well as staying updated on successful executions of your GRAX processes


This article is currently outdated and internal only.

Process Completion Notification

When configuring a hierarchy process or object backup, you have the option to be notified via email when the process completes. This is the easiest way to configure real-time alerting into job completion. The email alert will contain statistics about the job, including the number of records inserted and updated in GRAX, and a link for more details.

Process Error Notification

If the process 'finishes' with any of the following statuses, you will also get an alert, assuming you toggled the option to be notified by email.

Completed - Error Sending Data
Completed - Error Deleting Records
Error Backing Up Files to Storage

Custom Workflow Alerts for Status

Some GRAX customers also configure their own Salesforce workflow rules to keep updated about changing statuses. Behind the scenes, the custom object GRAX_Schedule_Process contains details about the specific job. There are a variety of different statuses that you could configure workflow rules to have real time insight into current status. Let's take a look at the various Status value definitions:

  • Running - The backup portion of this job (creating and packaging up the custom object GRAX Data Record and GRAX Data Record ID's) is currently in progress
  • Pending send data to GRAX - You may occasionally see this status if there is a batch waiting to be sent to GRAX (e.g. we are currently already sending a batch to GRAX which is in progress, but another is ready to be sent)
  • Sending data to GRAX - Records are currently being sent to GRAX. You would see under Salesforce's "Apex Jobs" page an active instance of batches being processed for the - GRAXBatchToResendDataRecords apex class
  • Waiting Files Backup to Complete - this is a special status you would only see if you are running an archive job AND 'asyncronous' objects are included. See here for more details.
  • Error Backing Up Files to Storage - this is a special status you would only see if you are running an archive job for 'asynchronous objects'. See here for more details.
  • Starting Archive Process - You may occasionally see this status if we are waiting to kick off a delete portion of a job, which will kick off at the top of the hour
  • Deleting Salesforce records - Delete batch job is in progress, so you will see under Salesforce's "Apex Jobs" page an active instance of batches being processed for the GRAXBatchToDeleteBackedUpData apex class
  • Completed - The process is done and everything was completed successfully
  • Completed - Errors sending data - There may have been errors when trying to send records to GRAX. We will try to resend up to 5 times, and then mark with this status. The archive portion of the job will not kick off as we were unable to send all records successfully.
  • Completed - Errors deleting records - This status is similar to previous, except it is when error arise in the delete portion of the GRAX job. We will try to re-delete up to 5 times, and then mark with this status.



Some customers like to have real-time WF alerts any time the Schedule Process status picklist changes to any of the above values, but in our experience this tends to be overkill. You will automatically get alerted on completion (or certain error statuses) if you select that option when creating the job.

We have also seen customers who like to be alerted if a process has been running for greater than X hours/days, as this can serve as a reminder to check in on it and make sure everything is running smoothly. It could very well be that the job has millions of records and will take days, but you could configure a time-based WF alert to send a reminder in 2 days if a job's status is not Completed. Once that job is marked completed it would automatically disappear from the time-based queue.

Reporting Options

Leveraging standard SFDC reports can also provide great visibility into GRAX processes and allow more granular detail into errors. Ensure the relevant GRAX custom objects are enabled for reporting:

GRAX_Schedule_Process - contains all the high-level information about the process you set up
GRAX_Data_Record - contains rolled-up information about the set of individual records being sent to GRAX as part of this batch (also referred to as GDR)
GRAX_Data_Record_Id - represents a single record that is being sent to GRAX, and thus provides granular record-level insight into any error (also referred to as GDRI)

One easy report that can be helpful to identify errors is the GRAX Error Report which you will see when you install the package in the GRAX report folder. Again, ensure the relevant objects are enabled for reporting or the report will error out. This out-of-box error report will show GRAX Data Records with GRAX Data Record IDs, and filter on any error records.

This report can come in handy to identify any errors, for example, if you run an archive process but a trigger blocks the delete of records. You would see the resulting error on each GDRI record. We recommend creating different reports in the sandbox as you test, finding what works for your business use case, and even scheduling these reports as needed.


GRAX Error Report Link

As an Admin, be sure to add the GRAX Error Report Link URL field to the layout of the GRAX Schedule Process custom object. This link will show potential errors for a specific Schedule Process, rather than you needing to go to the source report and then filter for the Schedule Process.


The GRAX Summary tab is another great, visual way to look back on all your GRAX processes and understand the summary statistics. You are able to filter by date, drill down into specific processes, objects, and inserts/updates to take a pulse of your GRAX processes.


GRAX logs will provide log-level visibility into connection issues and potential errors on the heroku side, as well as information about restored records, but the Logs tab is not meant to be used to identify status or success of overall GRAX backup and archive jobs. Use the other options mentioned in this article for that purpose.