Group buttons together into a single field and accessible by dropdown. Things like “push deadline” Then different buttons for 7 days, 14 days, other. Then others will ask user for value.
Ideally the placeholder for the button dropdown is a formula field. Meaning that the field can look like “Deadline” (as it is just a formula linking to that field). But on click it drops down the buttons to adjust deadline by specific increments.
Advantage to Rules + Single select:
Faster, allows user input, doesn’t look like an empty field if it has the Formula Placeholder. Useful screen real estate outside of just button.
EDIT:
Especially after hearing about focus on general improvements this next couple of months, I thought of some more clear use cases:
- Timer dropdown to start, stop, and reset timer in one field. As well as show total time until now, and indicate if timer is running. (if formula placeholder is included.)
- “Log Activity” for client tracking. Drop down for different activities, Calls, Meetings, Emails, etc. Each button click is an “Ask user for input”. (Or form popup, but thats a different request)
- Verify Document in Wiki. See Notion’s Verify feature. With this, it can be almost complete built out, custom, with the Fibery building blocks.
If anyone else wants to share use cases that come up feel free. I like feel this can really declutter the entity the entity view and make for a much cleaner end-user experience.
6 Likes
I’ve been wanting this feature for months now. This would go a long way to help users keep things more organized and would also make the button feature way more usable. As it stands now we have about 8 buttons for an entity type in our Fibery space, but we have avoided adding more because of how messy and unmanageable they have become.
I know this is not what you are asking, but you can access all buttons from … menu on entity.
So in general there is no need to show all buttons, you can use this menu
I think that most advanced users do not use buttons at all any more, but use Rules.
Rules are more flexible because they can be chained and the triggers have filters.
For example:
You can use rules that are triggered by a single select relationship field to a ‘Rule’ entity.
Instead of buttons, create Rules, that are triggered when a user selects a rule.
Each rule is triggered like ‘Entity linked to this entity’ (Rule).
Additionally, you can chain rules by adding a field ‘Date’ and make another rule set that to ‘Today’ (I call the field ‘TriggerTime’).
You can even combine both methods by creating rules that are triggered with field ‘TriggerTime’ is changes, and as condition that the select field ‘Rule’ is a particular rule, and then it will execute the corresponding action.
I’ll have to respectfully disagree regarding button usage. We are heavy button users and we actually leverage them to create entities that trigger rules, based on the data specified within them.
First, we create an “Actions” database, which serves as the central hub for orchestrating various actions.
Within Actions, there are numerous fields, primarily hidden single selects, input fields, etc that correlate to a specific tasks.
Let’s use an example:
We want to send an email to a Contact.
-
We create a button that when clicked, Adds an Action entity with a single select field (Message Type) specifying “Email”. We also ask for the clicker to select the Contact (which is a database with saved contact details like phone number, email, name, etc) and input the message.
-
When the action is created, it contains the contact, message and single select field.
-
A rule named Action Created: Email is configured and is something like: When action is created && single select field is “Email” && Contact.Email is not empty, send the email.
We had a lot of single buttons so to reduce this and to better organize our space, we did our own “grouping” of sorts.
Take the same example but instead of Email we want to Text the user using API. Since the action is nearly identical (really just needs contact details and the message), we can add an additional option (SMS) within the single select field available via the original button.
When we click the button, we’ll see Message Type [“Email”, “SMS”], Contact Entity, Message and a new rule named Action Created: SMS will trigger when Action is created && Single Select Field is “SMS” && Contact.Phone is not empty.
Buttons have been really helpful for us and allows us to organize actions within entity views, and/or right click to perform actions when viewing from tables and other views. Additionally, we can filter actions by what they accomplished, save responses in JSON format within the entity and even see who “created” the action. We love buttons!
1 Like
