-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include command to retrieve Record Counts in CLI limits plugin #978
Comments
Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments. |
Error while creating work item! |
Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments. |
This issue has been linked to a new work item: W-9160085 |
Is your feature request related to a problem? Please describe.
In monitoring of our Salesforce implementation we track trends in e.g. Data Storage consumption using the CLI limits plugin to extract this information and then import it into a tool which allows to plot trends over time. We are also interested in following the trends in number of records for select objects, e.g. the ones that consume the most data storage to allow us to identify needs to act on unexpected data growth.
What are you trying to do
Include the record counts (as returned by https://developer.salesforce.com/docs/atlas.en-us.230.0.api_rest.meta/api_rest/resources_record_count.htm) in the monitoring of our Salesforce implementation.
Describe the solution you'd like
Include this as a command in the CLI limits plugin with an argument that takes the list of object names.
Describe alternatives you've considered
We could call the available REST endpoint (see https://developer.salesforce.com/docs/atlas.en-us.230.0.api_rest.meta/api_rest/resources_record_count.htm) with e.g. curl as well but would have to provide the access token for authorization. This is much less elegant and potentially insecure as we'd have to extract the access token and pass it to the curl command.
Additional context
I'd do this as a community contribution if this would be considered a welcome addition.
The text was updated successfully, but these errors were encountered: