New Chart Type Suggestion: Hierarchy


Sometimes it can be very helpful to see connections between things in a literal sense. Prime example: Spec graph view.

This can be very helpful to illuminate the connections to things, and having a similar representation inside an AppSheet app as a chart could be useful in some instances.

I could see something where you add tables to a list (like selecting the columns that should be included in a chart), and we would see some sort of hierarchy chart showing how things are structured.

As always, thanks for considering! partyparrot (Appsheet)

Thank you for your suggestion.
Out of curiosity how would you expect to model this in your data table? One column defining each level explicitly? starting from the bottom? from the top? Or through a parent-child relationship style between two columns?
@Arthur_Rallu @Ben_Hare @jared FYI only…


I like it although you might to make some kind of self referencing design for it to really be viable


I can see how this could be hard to implement… :thinking:

  • I was imagining starting from the top of the hierarchy,
  • I was thinking the ref connections could be used to detect how things are connected
  • You’d select the top level, then the next level down, and have the ability to add X number of layers
  • I would think you could do the same “label” system you use for gallery views (for what text/visual should be shown) to represent each element
  • Perhaps the hierarchy starts as a gallery - since there will be the possibility of multiple hierarchies in your data - then once you select a starting point, you’re taken to a “drill-down” type of view with all the connections shown

:thinking: hmmmm…

With the above setup, I imagine the following:

  • You start by selecting the top layer, by select tables in your app, then add another, etc.
  • In the app, you see all the top layers as starting points (maybe displayed like a gallery or something)
  • When you tap on one of the options, the chart morphs where you’ve got what you selected at the top with essentially all the ref_rows shown below and connected with lines.
  • When you tap on one of the lower level options:
    • if there’s more layers defined in the view, the chart morphs with your selection at the top, and all child records shown connected below (rinse and repeat for each layer)
    • If there are no more layers, you’re taken to the detail view for that record.

With a practical example, this makes a bit more sense.

  • Let’s say that in my app I’ve got a table for employees, with a column that defines their “role” - this is a ref connection to a “role” table.
  • When I setup my hierarchy, I start by selecting the Role table; then I select the Employees table
    • and for another layer, let’s say I’ve setup a system to assign other employees as “subordinates” and so on each employee there is a list of subordinate employees (from a joining table).
  • So in my hierarchy view I would select:
    1. Role
    2. Employees
    3. Subordinates
  • In the app: It would be nice to see all the role options above (with maybe the employees clustered in a group that’s connected with a line)
    • When I select that group, everything expands so that only that role option is shown (essentially the same chart behavior of de-selecting something in the legend :wink: )
      • This would give me a chart with the role selected at the top, and all the connected employees (i.e. the Ref_rows for that role) as individual elements connected with a line.
  • Subordinates would be shown in the same method when I select an employee…

Thank you for your input. I am mostly interested to understand how you model the hierarchy in your datastructure to understand how we would envision the data binding. I am not as worried about the Editor user experience itself. That is pretty straight forward adfterwards.
So based on your employee example you are suggesting a parent child relationship with one column defining each employee and another one defining their subordinate. Most system that tackle it that way actually do it slightly differently, they have a column with the employee name or ID and one with the employee manager or mgrID, from then they can rebuild the entire tree structure.
That’s what I wanted to know.
I’m interested to hear from others on their opinion on that question too…


I agree with you @TDhers. To put it in more generic terms the data model would be something like:

ID ParentID <Detail Columns for ID>

Where Parent ID always refers to an ID in the current table. This approach is the proven industry standard to keep a clean data model using the requirement that a child can have one and only one parent.

If you flip it where the parent tries to list all its children then you are forced to maintain lists of unknown length. a bit messy.

To use @MultiTech_Visions graph above, The first two levels of nodes (yes that is a technical term :slight_smile: ) would be represented by the data table below. This model allows for any depth down the tree and for any number of children for a parent - limited only by the resources.

ID  Parent ID   Category
A    <null>      Income
B       A        Fun
C       A        Savings
D       A        Necessary
E       B        Purchases
F       B        Entertainment
G       C        Savings
H       C        401K
I       D        Food
J       D        Bills
<level 3 nodes>

I’m interested to hear how people would use this view.

What kind of interaction should each node have? (Popup menu? Assigned action per node? Dragging?)

What real-world hierarchy are you trying to model? (And why won’t a static image work?)

1 Like

Old feature request.

Hierarchy is crazy important.

I think the easiest way to define it, is with a specialty ref field, in which you can only choose the same table of which you’re on. Or in which you can sense when you’re referencing the same table. Most hierarchy that I’ve seen, simply has a parent reference. SAP projects, Primavera P6 WBS structure, etc. Also, the parent reference already works decently well to drill in through detail view with child records.

Massive need for this . I have reconstructed entire data sets and databases, just to get around the lack of hierarchy. I’ve also lost jobs to power apps due to Appsheet not being able to have an expanding tree.

Just mention hierarchy and me to @praveen and I’m sure you’ll get a chuckle. Hehehe.


I did exactly what frustrates me about people posting here in the community:

  • I didn’t search for the topic first. :frowning_face:

Curious that the post you shared, which is literally named exactly what I was proposing, wasn’t shown in the suggested topics when I was building the post.


It’s cool. I feel you!


I guess at least it brought the topic to light again.


And fresh perspective!


We did a workarond to achive this. We need this feature for construction sites.
So we used google charts and made the tables ORG CHART and ORG CHART CHILD.
By making an action taking you to a “”-page, we made a script from google charts with the data from the tables. Making this URL in a VC.
Works fine, but opens in another browser of course.
Ill paste it here:
google.charts.load(‘current’, {packages:["“orgchart”"]});
function drawChart() {
var data = new google.visualization.DataTable();
data.addColumn(‘string’, ‘Name’);
data.addColumn(‘string’, ‘Manager’);
data.addRows([" &
var options = {‘allowHtml’:true,
var chartDiv = document.getElementById(‘chart_div’); = ‘13px’;
// = ‘3000px’; = ‘none’;
var chart = new google.visualization.OrgChart(chartDiv);
chart.draw(data, options); = ‘block’;


This is a very good request and also referred to as a Treeview control. Very usable for any kind of data structure that you need to display in a hierarchy.


+1 to hierarchy view, implementing it similar to the way google sheets does it would be a great first step. Trying to map an Org Chart using appsheet using a deck view, but a hierarchy map would be brilliant to visualise this.



I use Google charts as in this demo app:


Hi , would you be willing to share your demo app.