Salesforce IdeaExchange
Force.com Platform Comments
| Force.com Platform Ideas
|
Reports and Dashboards Comments
| Reports and Dashboards Ideas
|
Delivered Ideas Comments
| Delivered Ideas Ideas
|
Release Winter 09 Comments
| Release Winter 09 Ideas
Dashboard and Reports API
I've had a number of requests from partners for an API for Salesforce dashboards and reports. I'd like to hear your use cases for this and understand it's importance relative to some of the other ideas that have been posted so far.
27 Comments » Posted by dcunni
Posted 10/12/06
Categories: Force.com Platform, Reports and Dashboards, Delivered Ideas, Release Winter 09
|
CRMfusion_-_GW 10/17/06 |
This is a vitally important feature. By opening up the API for reports it will permit developers to build report management tools to assist the organizations that have hundreds of reports and need to manage them outside of the salesforce UI. Ideally the API would expose all aspects of reports and allow for the full creation and updating of existing reports. Plus the ability to delete existing report objects. Glenn Wilson – CRMfusion Inc. |
|
cwood 10/18/06 |
I agree that this is a super-important feature. By opening API access to reports, you can punt to partners a lot of the other reporting feature requests like scheduled report delivery, etc. And since this is the #1 request I get for Spanning Salesforce feeds--from SFDC SE's--I assume there's some good demand for it in the field. |
|
tt 10/18/06 |
what about dashboards and dashboard components and controlling the running user? What about being able to access report metadata but not the results? So you could change a report but not run it from the API? Would it be better to run it but not change it? Would you accept other rate limits than the rest of the API on the reports? That you could only run reports 10 times an hour? |
|
kgierach 10/18/06 |
This is a highly important feature for our firm, AVST, Inc. One of the focuses of our product is Unified Messaging, provided via text-to-speech technology for mobile users (cell phones/ handset phones). In order to successfully integrate our product with Salesforce.com, we need to have access to report data, and report metadata, as well as dashboards, which I view as collections of reports. I don't believe we have an immediate need to create/delete reports programatically as some others have requested. |
|
CRMfusion_-_GW 10/18/06 |
In response to tt ==> There would be no need to run the reports via the API. With the Joins we have in the Winter '07 version you can execute more detailed reports via the API than executing existing reports. I see there being 2 options from the salesforce side for exposure to the API: 1. Basic report names, category and the ability to rename and delete reports. Maybe the basic makeup of the reports 2. Full access to the reports with the ability to create and edit existing reports including changing fields, field summaries, etc I would love to see #2 but I would still be happy with #1 if it could be pushed in early |
|
gdavies@upside-outcomes.com 10/18/06 |
Glen I disagree - running the report and retrieving the ID's of returned objects could serve an interesting function in analysis. If you want to compare the results of one set of data vs. another then selecting the different sets can be very difficult. Say (as a simple example) you had an algorithm fo comparing "success rates" for opportunities. Then you may want to compare the "Success Rate" between reps, or between geography, or between time periods, or for different products. All of that ad-hoc assembly of queries can be generated and stored by a user using the tools available in SFDC. Then running the analysis would be a matter of sending a reportID to the algorithm and recording the results - this would mean that, as a developer, you don't force the user into your fixed patterns of groupings - or have to write a complex general selection engine. By keeping the selection in Reports you also enable the ability to piggy back on things like dashboards. As a follow-up request, therefore, what about making an APEX "verb" available to line-items in reports and totals of reports, that'd be cool for the anaytics crowd. |
|
flescor 01/12/07 |
Please O please can we have the Forecast reports & metadata over the API!!! |
|
CM@affy 06/15/07 |
Would love to be able to mass move reports from one folder to another, apparently something we cannot do today with or without DemandToolz. |
|
jhbenter 07/20/07 |
I would also like to pull report data through the API. That way you could easily implement feature like scheduled emailing of report data with a reference to the GUI report. When you change the report in the GUI it will also automatically change the data pulled from the API. |
|
hemm 07/26/07 |
This would be fantastic. I can envision lots of development situations where the SOQL could be based from a report rather than buried in the code. This would allow us to build apps/s-controls that leverage the data from already created reports and process that data in unique ways. It also puts the power of the query in the hands of business people rather than techies. If the cirteria of a process needs to change after implementation, it is not a call to IT. Rather, the business owner of that report could simply modify the report criteria. Of course, security around these special reports would need to be well trained, but that's the responsibility of the customer and the implementation partner. |
|
CM@affy 10/05/07 |
Then we could.... * Mass delete unused reports. * Mass move reports to different report folders. * Mass rename reports to standard naming conventions. * Understand which reports are used by dashboards (rather than Delete-n-see) . * Find who has access to a report. * Etcetera, etcetera... |
|
Cheryl 10/10/07 |
We've been asking for this too -- we have thousands of reports and would love to.... * Mass DELETE reports! * Mass move reports to different folders * Mass rename reports I'm sure my IT people could think of other reasons they'd like it for reports and for dashboards. But it's a winner for us if we can just do the things noted above. |
|
hemm 10/21/07 |
Merged Idea
originally posted 07/26/07
Obtain SOQL of Existing Views/Reports
I would like to request some capability to obtain the WHERE statement already defined from Views/Reports in the application.
It would be a great addition for third-party apps & s-Controls to be able to utilize already configured queries (Views and Reports) rather than having to reconstruct the SOQL. |
|
Tom_Tobin 10/21/07 |
Merged Comment
originally posted 07/26/07
would you want to be able to access the report over the API and change the criteria and get the results?
|
|
hemm 10/21/07 |
Merged Comment
originally posted 07/26/07
I think the idea at http://ideas.salesforce.com/article/show/23850/Dashboard_and_Reports_API better expresses this idea. At first I was thinking of getting SOQL based on a View/Report and then doign what I want. However, a more robust API to interact with data from a report would be better.
|
|
aezell 10/21/07 |
Merged Idea
originally posted 08/31/07
API Access to Reports
Provide a set of API methods through which one can access Report objects.
Some examples would be methods to: 1) get all reports in a list 2) get data about a single report 3) get the data generated by a single report (perhaps filtered by a SOQL query) |
|
maryam_norouzi Mar 19 |
Enabling Report APIs will enable us to implement a number of very useful administrative functions(some have already been mentioned): * Mass delete selected reports * Identify obsolete/unused reports * Identify reports using obsolete columns/objects * Create/Update reports |
|
jeremyw May 14 |
This would be great to be able to get the data from a report. Perhaps returned as XML or something. The reason for me would be to merge together various reports into one view. Even if the amount of times it could be executed it would be fine as the report data is not required to be updated more than once every few days. |
|
tt May 14 |
Changed status to Ideas Under Consideration. |
|
tt May 14 |
It's under consideration apart from running the report and getting the results. |
|
louf@bluewolfgroup.com May 15 |
It would be great if I could see the "signature" of report so I can tell very quickly if a config change will cause a report to "break". For example: If we were to change the stages of an opportunity, I would like to pull the signature for all reports so I can grep through the reports to see if which reports this will affect. |
|
KT-MSMITH Jun 6 |
This would be a great feature to have for us system administrators. It could make managing the hundreds of reports we have a lot easier by using an API to periodically review and possibly delete unused reports. |
|
gribis Jul 21 |
We have several needs where SalesForce Report Data pulled via APIs could make a difference. - Display current support metrics on the company internal site - Merge multiple reports into one combined report This only scratches the surface of what could be automated. Pulling report data and formatting such does take up way too much time of our managers. |
|
tt Jul 21 |
louf - If you wanted to know what would break, you'd need to look at all the possible reports. What would break would be different if you were replacing a standard field with a custom one, or changing the names of Opportunity stages. I don't think an md5-style signature would cut it - that would just tell you if it was broken by a given change in sandbox. |
|
tt Sep 23 |
Changed status to Coming in Winter 09. |
|
ad75 Oct 13 |
Winter09 now allows reports definitions to be edited via the API, which is great. But reports cannot be executed via the API. Please could this be considered as a further idea? It has been mentioned above several times - what is the reason for not implementing report execution please? We can already generate very large result sets by exporting report results in excel format from the browser UI, so it seems that downloading large datasets is not a performance problem, and also that much of the functionality already exists (?) This would be very useful for any AppExchange app which includes some kind of reporting or data aggregation function. Currently due to the lack of SOQL aggregation functions like SUM, MAX, AVERAGE etc, these apps have to download large amounts of base records from the API then process the records in a custom remote client or server app before presenting the results. Downloading all the base records then analysing them remotely every time is very inefficient. It seems much more efficient for the reporting and aggregation to be done on the force.com platform, and just the results sent to the client. It’s true that Apex code can be written to work around this to some extent but (a) this is only available in EE and UE, (b) governor limits can limit the usefulness, (c) it’s not as easy to write Apex code as to define a report in the browser for many users and (d) this involves re-inventing existing reports in Apex code. |
|
marilynl Oct 14 |
Changed status to Delivered. |
Please log in to post a comment
last 100 promotions:
- supporties
- nate_manley
- Kendo
- jmeketa
- larryssuggestions
- ad75
- ron_hess
- k3rmit
- michaelkahle
- RodbCA
- stuart.jones10182007
- chris_mail
- partnership@bsquaredinc.com
- toby_baier
- okan
- bhare
- cribis
- WYam
- Sunny
- Kyler
- chw
- Tom_Tobin
- gribis
- krimbo
- crispy
- jimson
- adab
- hpKOONJ
- Jesterale
- GMP
- bradley_herman
- m62Admin
- lorcanore
- sherwin
- CRMSuggestions
- rob_ocp
- md1
- ericsu
- EricCH
- Paul_Vine_@_salesforce.com
- sparky
- craskulinecz
- TrevorIDP
- KT-MSMITH
- Rainmaker
- Rusty12
- willscarbrough
- alex.lares@v2sa.com
- paulMcGurn
- jeremyw
- rnichols
- Odemuth
- ursula_llabres
- arlon_wilber
- paul-lmi
- GlennAtAppirio
- rosa
- SimonF
- maryam_norouzi
- njdevilsfan
- smithsnk
- kirill
- sherrie98
- RafCon
- djacobson
- nikola
- Eirik
- kah8315
- 05/28/2007_6:47
- greg101
- radliberty
- cjones613
- jim_testa
- Kissa
- mlee
- davferg
- tphelan
- Suzanne_JW
- at
- EricB
- SellingInVegas
- jfrey@corpsyn.com
- jeremyfrey1
- dwachtel
- Cheryl
- gr
- TessKTigart
- jmarinchak
- NigelHavers
- michel_m.
- freshnails
- Schlinkdog
- sajones
- PDV
- OridiansPH
- TomaszOczapowski
- aezell
- Chrisr
- Xiidaen
- faun.clark@intergraph.com