During our last annual credit period, about half of our credits (~2300) were used up by a rogue/test process. The users thought they had stopped the process, but it either continued processing (loading??) or it had already used the credits. In this case it wasn’t critical, since we didn’t run out of credits, but with the new credit period just starting we are hoping to prevent this. [btw - since we are all learning are way around still, it could happen to any of us]
To help, I just activated the Configure credits—ArcGIS Online Help | ArcGIS for our enterprise account and have allotted a small amount of credits per user. (10-25 pre user)
But the question was asked, “What happens when a user hits their limit during a task/process?” …and I would add, “rogue/test or legitimate?”
She was able to find “If members exceed their allocated credits” on the same page as the link above which states.. (emphasis added)
Some members may use ArcGIS credit-consuming functionality extensively and, in the process, exceed their initial credit allocation. If this happens, designated administrators will receive an email notification that the member has exceeded their allocation. The member will also receive a notification advising them that one or more administrators have been notified that their ability to perform batch geocoding, network analysis, spatial analysis, geoenrichment, demographics, elevation analysis, and tile generation will be suspended until their administrator updates their allocation. As a designated administrator you can either set their allocation to no allocated limit or provide them with additional credits using the same tools you used to make the original allocations. Alternatively, you can contact them directly to confirm that no additional credits will be allocated to them
This is a little vague to us regarding:
I think what we would hope for is, it the limit is hit and we get the email, that the process would immediately pause, and then allow us to either allocate and continue or cancel.
If a low limit is hit and the task (or storage ??) is paused, it would give us a chance to review whether the storage/process is the best use of the credits or if there is a better alternative. (so much of what we have done thus far has been learning testing, but we are starting to get more real items in place.)
I understand the
"Some of your organization’s total number of credits may be consumed through storage, premium content, and app-related activities. You may find it advisable to maintain your budget with these activities in mind."
but, it's more the evening/weekend work, or the testing of something just to find out what it does, that is, the things you can't predict, with the wide distribution of users and needs, that this post is most concern with.
Thanks
Solved! Go to Solution.
Hopefully this answers your questions, but please let me know if i missed anything.
Most processes can'y be run through ArcGIS Online if you haven't been allotted an amount of credits to complete the job. For analysis or tiling jobs, the user will receive an error indicating they can't submit the job as it exceeds their budget.
Batch Geocoding is an exception as it can be used in many products. If a user submits a job that exceeds their budget the process will run until the budget is used. Once the budget is used the rest of the job will be cancelled. It will not start back up once the budget is replenished.
Feature Storage is not allocated to an individual, so is charged outside of the credit budget allocation.
To sum up, most tasks prevent users from submitting jobs that are over the credit limit so they can't run into an issue where they exceed their limit during a process.with geocoding, the job will be cancelled when the limit is reached.
-Kelly
Hopefully this answers your questions, but please let me know if i missed anything.
Most processes can'y be run through ArcGIS Online if you haven't been allotted an amount of credits to complete the job. For analysis or tiling jobs, the user will receive an error indicating they can't submit the job as it exceeds their budget.
Batch Geocoding is an exception as it can be used in many products. If a user submits a job that exceeds their budget the process will run until the budget is used. Once the budget is used the rest of the job will be cancelled. It will not start back up once the budget is replenished.
Feature Storage is not allocated to an individual, so is charged outside of the credit budget allocation.
To sum up, most tasks prevent users from submitting jobs that are over the credit limit so they can't run into an issue where they exceed their limit during a process.with geocoding, the job will be cancelled when the limit is reached.
-Kelly
Thanks Kelly. That helps a lot, but I'll check with my coworker Monday to see if that covers her question/concern. It is good to know that AGOL estimates the credits needed before staring the task (with the exception noted for geocoding).
It also makes sense that storage would be to the org and not individual. Hopefully, if it would be an issue for us, the task of loading would hit the limit and give us a heads up before it is an issue. In anycase, the storage credit usage itself seems to be a slower "drain" of credits. Currently we use about 5/day.
Follow up question ...
is there a best practice or rule-of-thumb suggestion as to what credit limit we should assign, general Level 2 users...that may not have a full grasp on the credit usage? Most of our users/publishers are just starting to use it for real, but we are all still learning (myself included, although maybe more intermediate knowledge). I started with 10 for the general, occasiinal user, and 25 for the GIS staff which will also be supporting OpenData and other apps that may rely on AGOL. Is 5/15 better limits?
I know that is subjective and is the typical "it depends", but I would rather a user gets a notice and ask for additional (in which case GIS staff could review and determine if that is the best platform before they eat up our credits. (Most of our users are biologist, not full time GIS users). Is 5 too limiting?
thanks
Great question, and you're absolutely right, it depends but here are some things to consider:
You want to ensure that you users have enough credits for your users to be able to complete their work unimpeded but enforce responsible use. Consider if what credits your users will be using, geocoding? spatial analysis? tile generation? Use the view status dashboard to get an initial idea about how credits are currently being used in your organization.
View status—ArcGIS Online Help | ArcGIS
When and how do your users typically use credits? If geocoding, do users usually geocode a few addresses daily, or many addresses? Sometimes large geocoding/tiling jobs only happen a few times per year, so you can keep the general credit budget low and increase it when the large jobs are occurring.
What would be the typical size of a reasonable job the users would perform? You want to ensure that the budget is large enough that users can be successful with their daily work without running out of credits all the time. Data Enrichment, geocoding and generating tiles are generally the largest single job credit consumers, so base your budget on being able to complete these tasks.
Try something out and don't be afraid to revise. Find a user that fully uses ArcGIS Online (maybe yourself or everyone) and set a test budget. See if you run into the upper limit often and increase if needed.
This learn ArcGIS course has examples of doing credit math to better understand estimating credit usage:
Monitor member activity—Set Up an ArcGIS Organization | ArcGIS
Credits:
ArcGIS Online | Service Credits
-Kelly
Thanks again Kelly.
My takaway for our situation I think is, keep the limit low and communication so users know they can ask for more if needed. I think tile creation would be our issue (not so much geocoding or enrichment) and we have other options for that.
i marked your first answer as correct, but both are very helpful. Thank you
edit: adding like to blog ArcGIS Online Credit Budgeting and Allocation Tools | ArcGIS Blog
Excellent information yet again Rebecca (and Kelly!)