Yesterday I noticed a new field type “Json” and was able to play with it briefly. But today it is gone 
It shows up if the alt key is pressed when creating a new field.
There also seems to be a bug that sometimes the browser believes the alt key is pressed when it isn’t (so you might see it without even trying).
1 Like
You have it get it on the first try – if you release ALT and then press it again, the extra fields do not show up again 
I think the behaviour varies by OS and browser 
Sometimes the browser ‘catches’ the alt, sometimes it passes it through.
1 Like
It appears that a Json field content is only accessible via Javascript.
Are there plans to allow Formulas and No-code Buttons to access them? That would be SUPER useful 
1 Like
I don’t think there is really any expectation for an average user to add the JSON field, so making it accessible via formulas/automation actions is pretty unlikely.
What’s the actual use case you have in mind?
I was thinking it would be a good place to hide entity info from the user. And it might provide a way to emulate some polymorphic functionality… though I haven’t looked into how that might work.
If scripts/Rules could hide/show an entity’s fields on a per-entity basis, that would be one way for a single Type/DB to act polymorphic.
@Chr1sG
Is there any existing or planned functionality for the Json field type, or is it exclusively for script use?
There’s no immediate plans to support showing/hiding fields on a per entity basis, nor for show/hide to be controllable using automations I’m afraid.
Also the JSON field is not really for public use - i have no idea what use the devs put it to
1 Like
Here’s a use case: In my “Page” DB I have a “Current Step” one-to-one relation field that links to a Task, but the Page has no Workflow/State of its own (the individual Tasks have States). A bunch of Tasks exist for the various steps of a Page’s workflow. When one of these Task is completed, a Rule updates the corresponding “Current Step” link to the next Task in the Page’s Workflow.
“Current Step” really should be a Formula, because it is intended as a “read only” field that users cannot manually change. But it is difficult/impossible/ugly to implement as a Formula, so I use Rules to set it.
This is undesirable, because since “Current Step” is just a Relation, users may not realize that it is automated, and should not be manually changed.
So here’s my JSON field use-case to solve this:
The Rules would store the “Current Step” link in JSON (in some form), and then the visible “Current Step” field could become a Formula that looks-up and surfaces the actual Task. Thus users would not be tempted to manually change it.
Then my Rules would update the linked Task in the JSON field, instead of updating the “Current Task” relation, and the Formula would surface this relation for the user.
This is all just a complicated way to try to make the “Current Step” relation read-only from a User’s perspective, because implementing it as a regular Formula is difficult/impossible - much easier with Rules.
Better solutions would be:
- Have ability to make a Relation field “read only” for the UI (only set it from automation), or
- Have ability to hide the actual relation field, and surface its value in a Formula field
Out of interest, what is the trigger for updating the task linked to the page?
Does the user somehow mark the task as done?
Yes, the Rule triggers on Task State updated to “Done”.
If a Page has a one-to-one relation to a Task, that implies that only one page can be associated with a given Task.
Are the Tasks based on a set of ‘template tasks’?
Does each page follow the same ‘workflow’?
How is the ‘next task’ linked to the ‘current task’?
Page has a One-to-Many relation to Tasks - so a Task can refer to at-most one Page.
Tasks have no explicit template, but I do have a Button to create a default set of Tasks for a new Page, to shepherd the Page through our typical Page workflow: Write → Review → Build → Proof .
Additional Tasks might also get created for a Page at any point, to address issues or design changes that come up.
Tasks have a “Dependencies” and a “Dependent On” relation (to other Tasks), and a “Blocked” Formula that looks for any blocking Tasks (i.e. any Dependent-On Tasks that are not Done).
How Tasks are linked in a series:
This is done with a Button currently (maybe with a Rule later):
Those Task Dependencies encode the sequence of Workflow states; the “Build” Task depends-on the “Review” Task, which depends-on the “Write” task, etc.
When Task State → Done, this affects the “Blocked” Formula for any Dependent Tasks. When a Task transitions from “Blocked” to “Unblocked”, a Rule notifies its Assignees (and maybe changes its State as Well).
But I am also considering a more structured, more general (and more complex) way to do all this.
Thanks for all that detail.
So am I right in thinking that Current Step would ideally return just one of these linked Tasks?
Can you not just use a formula field something like this:
Tasks.filter(State.Name != “Done” and Blocked = false).sort().first()
It assumes that at any point in time there is only one not-done Task that is not blocked.
And the user can’t edit this field, the only thing they can do is just mark the Task that is the current step as Done.
By the way, it looks like step 3 of the automation needs fixing because of a deleted field.
1 Like
That will not work once additional Tasks are created for the page, as the “Current Step” field should be restricted to just the Tasks in the standard Page Workflow.
But I could use something similar if I can tweak the filter to only include standard Workflow Tasks.
I would hate to create another field just to distinguish those tasks, though - “Current Step” is just a convenience field (but there’s another good use for JSON accessibility in Automations 
– for keeping track of little bits of info like “is this Task part of the Primary Page Workflow”).
Overall, I think this option - to be able to define fields to be read-only (from a UI perspective) but which are capable of being modified by automations - would be very useful in many situations.
It is currently possible with scripting to make user-defined fields read-only, but such fields are not updatable via automation.
You could actually do the specific sequence:
make read-write, update, make read-only
but it’s hacky and temporarily exposes a field as editable by users, albeit briefly.
2 Likes