function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
bbradybbrady 

Question about the scheduling-limits of Analytical Snapshots

I see in the Editions & Limits documentation that I my DE org may have up to 200 Analytical Snapshots but that the scheduling is "(Limited to one preferred start time per day, which cannot be changed)"

 

I interpreted this to mean that all snapshots would begin at (about) this time, which would be fine, but my experience is that I am only able to schedule a single snapshot to run at all! 

 

Is this the case, or have I encountered behavior that warrants a call to support?

 

Thanks!

Bill

RickRRickR

I have encountered the same problem.  Have you received a response from anyone?  Did you have to go to Customer Support with this?

 

Thanks for any feedback.

 

Rick

bbradybbrady

I did ultimately speak with tech support about the issue and they confirmed that it is working as it is supposed to.

 

Perhaps Analytical Snapshots are generally more resource intensive than mine, and I'd guess thats the reason for the limitation. Allowing only a single snapshot to be scheduled seems a bit arbitrarty, however. I ended up developing an Apex class as a workaround.

InnovationInnovation

Sorry to rehash an old thread, but can you elaborate on the function that this class you mentioned performs? We're facing a similar situation, and have come to the conclusion that we need a programmatic solution, but we haven't been able to fully conceptualize the most effective outcome. Are you launching the snapshots by scheduling and executing the Apex class?

 

Appreciate the insight.

 

 

 

Mike

 

 

 

bbradybbrady

Our goal was to calculate the average value of a field in a collection of related list records and write it to the parent record. We could have done it easily using roll-up fields, but we didn't want to impose the contstraints of the master-detail relationship.

 

Snapshots will work as well but the constraints that SFDC places on their use makes them unsuitable. We ended up writing an Apex class that gets invoked by a trigger. 

 

Our need seemed generic enough that we thought SFDC ought to handle it out of the box - and they do as long as its a master-detail. We thought snapshost were going to be the answer, but I we didn't understand their intended use when we originally posted the question.

 

 

InnovationInnovation

Got it.  Thanks for the clarification.  Our use case is to create summary data tables so that we can have a point-in-time reference of KPI's across a number of related objects.  Analytic Snapshots make perfect sense, but the scheduling limitations have become a source of frustration.  The documentation implies that your specific Salesforce edition has limitations on the preferred time(s) for executing the snapshots, but that the total number of supported snapshots is up to 200...what we have found is what others are describing, that once we schedule one snapshot, we can't schedule any additional snapshots because the Preferred Start Time dropdown is required to have a value defined, but the only value available is '--None--'.

 

 

InnovationInnovation

To land the plane on this, can someone at salesforce.com confirm that the number of Analytic Snapshots that can be utilized directly correlates to the Preferred Start Time limitation for a specific edition?  And can we get clarification in the documentation to reflect this more clearly?  Basically, if you're in a developer org, you can only schedule a single Analytic Snapshot...if you're in an Enterprise Edition org, you can schedule 3 Snapshots, and if you're in an Unlimited Edition org you can schedule 24 Snapshots (assuming the 1 preferred start time per hour translates into 24 available start times)?

 

 

tttt

The number of snapshots/day is limited by their start time, so the slot limits do control the number you can run.

 

You can have unscheduled snapshots, so you can define more than you can run.

 

Since packages can't install a schedule (users have to schedule them once installed), not having all schedules running in DE orgs shouldn't be a problem.

Enterprises can get more slots.

 

On a more conceptual note, the slots are designed to:

1) space out load over the hour when they are scheduled

2) make orgs space out work across the time available

3) make sure orgs don't affect other orgs when scheduling

When we looked at the reasons customers would want to schedule at one time rather than another, we kept coming back to the problem that many orgs would want dashboards, reports, and snapshots all run at between 6 and 8 am on Monday morning, for all their users. To avoid overloading the service, we wanted to make sure that the load is spread out, and that companies can look at their own processes and decide when to schedule items, given the constraints.

DE has one slot mostly we thought that DE orgs will test something, then want to stop it. If you want to test your package - a whole system of triggers, snapshots, scheduled apex, reports and dashboards, then you'd install in an EE org to make sure it all can run.