asked on July 30, 2025
The pivot table does not show all field values.
I'm developing a custom api, and I get all the items in the api's /select response value.
However, in the pivot table, only the grand totala is initially shown in the cell.
And if you change the option to flat and then pivot again
Other values are also added to the cell.
Even then, all values are not visible.
All request body and response body contents in /select are the same.
I want to show all the responses to the cell from the beginning.
⋅ July 30, 2025
Hello,
Thank you for writing to us.
This issue arises due to the server incorrectly handling the request and returning an invalid /select response structure. Please note that Flexmonster uses different request and response structures for different types of the /select request:
You can check the Network tab in this JSFiddle example to see the correct structure of the /select response for a pivot table. This working sample can serve as a guide for aligning your server’s response accordingly.
Please let us know if any further questions arise.
Best Regards,
Maksym
⋅ 7 days ago
Hello, I'm a colleague of jhsin
What we're curious about is that the screen in the same select response is different from the screen in the first classic when we switched the flat and switched the classic again.
It seems that only one field and its members are visible when it is the first classic screen.
The API of the field and member is the same response value, but I don't know why it's happening, and I would appreciate it if you could tell me how to solve it
⋅ 7 days ago
Hello,
Thank you for providing us with more details and screenshots.
Now that we see the screenshots and part of the network requests, we have some ideas about what might be happening. However, since we do not have access to your environment and can't inspect all requests and responses directly, these ideas are educated guesses that require further investigation on your side.
Below are several possible reasons that may have caused such behavior:
"keys" object - this is the most likely reason, which is supported by screenshots. The slice shown in the Field List has only two rows, yet the /select response from the second image has a third field in the "keys" object. The third key is absent in the response on the last image, where the pivot loads successfully.Other reasons may be:
keys object)./members response upon initial loading or mismatched members compared to the /select request.For reference, you can examine server responses in this JSFiddle example with a similar slice: https://jsfiddle.net/flexmonster/voLyx4u1/
Please let us know if our answer was helpful.
Best Regards,
Maksym
⋅ 3 days ago
I'm sorry.
I posted the wrong example picture
These pictures are accurate examples, and the important point is that the two pictures respond equally
I don't know why I can't see the values on the first screen
⋅ 3 days ago
Hello,
Thank you for sending the updated screenshots.
We reviewed them and saw that the responses in both cases are similar. However, since we cannot access your environment and can only see part of the server responses, we cannot say what is causing the issue. But based on what we see, we believe the problem is likely happening on the server side.
To resolve the issue, we recommend looking at this example of Flexmonster connected to our custom API server: https://jsfiddle.net/flexmonster/84qpy3gs/
In this sample, the server responses follow the correct structure, and the data loads as expected. We recommend creating similar slices on the JSFiddle sample and your system, and then comparing /members and /select responses. This can help identify what may be different or missing in your implementation.
Please review the server’s logic and responses carefully. Pay close attention to the points described in our previous message:
"keys" object in the /select response./members and /select endpoints.If you are still experiencing this issue after examining the responses, we would appreciate it if you could share access to the page where the problem occurs. This would allow us to investigate the issue more closely and help you find a solution.
Let us know if any further assistance is needed.
Best regards,
Maksym
⋅ 2 days ago
i will show you our actual response with masking
is Response body structure wrong?
/members
{
"members": [
{
"value": "America",
"id": null
},
{
"value": "China",
"id": null
},
...
],
"sorted": false,
"pageTotal": 1,
"page": 0,
"nextPageToken": null
}
/select
{
"fields": null,
"hits": null,
"aggs": [
{
"values": {
"saleTotal": {
"sum": 23678
}
},
"keys": {
"groupName": "America"
}
},
{
"values": {
"saleTotal": {
"sum": 28734
}
},
"keys": {
"groupName": "China"
}
}, ....
{
"values": {
"saleTotal": {
"sum": 810828
}
}
}
],
"page": 0,
"pageTotal": 1,
"nextPageToken": null
}
It was confirmed that all values that exist as keys in /select exist in /members.
Symptoms are similar every time.
1. At first, I can only see the grand total
2. If I change the option to a flat and then back to classical
3. The keys that were not visible are visible on the screen.
4. In this case, some of the keys that come in response are still missing.
5. It was confirmed by the network tab that the requests and responses of 1, 3 are all the same.
⋅ 1 day ago
Our data comes from 10,000 times per page. Could the size be too big be the cause of the problem?
⋅ 21 hours ago
Hello,
Thank you for sharing additional information with us.
We have reviewed the provided /members response and noticed that you are adding "id": null for each member. This is the root cause of the issue; it is unrelated to data volume and server load. To clarify, here is how this property works in Flexmonster.
When you define an id in the /members response, Flexmonster will use that value in the /select response when processing the "keys" object. In your case, all IDs are set to null, so Flexmonster ends up using the same key (null) for every member, which is not defined in the /select response. This causes conflicts and incorrect behavior in the pivot.
We recommend entirely removing the id field from the /members response. Also, not setting redundant null values in the custom data source API responses is generally a good practice that may help to avoid similar issues.
Please let us know if removing null IDs helped you.
Best Regards,
Maksym