We’ve added a new ‘Reminders’ template to the gallery:
As the name suggests, it adds reminder functionality to your workspace.
It’s really simple to use:
just start typing #Remind me anywhere you want to set a future-dated reminder for yourself, and then pick how far ahead you want to be reminded.
In this case, you’ll then get a notification in 1 day’s time 
You can define your own custom options for the number of days ahead, if 1, 7 and 30 don’t suit.
6 posts were split to a new topic: Lack of Work Management features in Fibery (Reminders, Dependencies, Notifications, My Work, etc.)
Thank you, I think it will! I appreciate you figuring this out and sharing it in the meantime. 
This doesn’t work anymore as well anymore - the “item url” doesn’t work and some “GetEntitybyID” function doesn’t work anymore either so it gets disabled 
Have you made any changes after installing the template?
The database need tutorial workflow step by step , play book of the task , many learner take more time via trail error , long time .Even monday.com very good board the time to learn is very long
Thanks for these comments @Oshyan and @B_Sp on the pull and push on native functionality and keeping Fibery flexible.
I have always been secretly hoping that we will see more development on the “Extension” types (now called “Advanced”) and we would eventually get to the point that the community/developers/etc. can start building more complex data types on top of Fibery that use Fibery’s flexible data structure but hide all the extraneous details from the end user. Fibery itself is kind of doing this for things like Single Select fields which are really databases under the hood.
I think having an extendable field/type system (possibly one that allows some form of inheritance) with an easily to customize UI framework to ensure consistency, can really allow Fibery to grow much more quickly.
In addition to reminders, I see this coming up in many other areas:
Contact management: if I want to add multiple phone numbers or emails to a contact, I will either have to hard code additional fields or build separate Phone and Email databases. This approach works and makes sense but the current Fibery UI adds so much friction that it is not viable for a production system for a normal organization. We can definitely ask the Fibery team to extend the phone number type to add this functionality, but the usual response has been that would be too prescriptive and it is not worth their effort.
Recurring items: like reminders, if you want the same item or a template created on a regular schedule, you need to completely develop this from scratch. The solution I have now works, but it is impossible to explain it to others and can’t be added to new databases. It is also not comparable to what very basic task/project management tools offer. If I show this to decision-makers in my organization, Fibery would be written off very quickly.
As Fibery matures, I think we need to be able to move beyond “well you can technically do this in Fibery” (if you are willing to create extra databases and have a whole bunch of helper fields). monday.com’s custom column types and coda’s packs ecosystem open up the platform to more polished solutions without making all the decisions for the users. However, if you are dissatisfied with the implementation, Fibery gives you all the tools you need to roll your own solution.
Sorry again for yet another long (probably off-topic) post.
I’m a bit confused by your comments here. We do all of our contact management in Fibery and have a full CRM which includes all orders, line items, total spend per customer and way more. We have a separate database for emails which has the ability to set a particular email as primary. In terms of adding a new email address to a contact record, it is as simple as one click, type it and hit enter. I’m not sure how much simpler it could get that that. To update an email address, it is a single click and type.
What is it exactly you’re referring to by “Fibery UI adds so much friction that it is not viable for a production system for a normal organization”?
Yes, I would love this!
With this concern, do you mean for example that you must have separate phone # fields that are hard-coded with the name (e.g. “Work” vs. “Cell”, or “Other phone” to make it generic, or “Phone 1, 2, etc”), and that all fields always show up? Whereas in a dedicated contact management system you often can have just 1 phone field visible by default, and even name it or set a type for it (e.g. a dropdown with work/home/cell/etc.), and if you need additional phone fields you can e.g. click + to create as many as needed. This kind of thing is valuable for that use case, and potentially many more, a sort of auto-expanding “set” or “group” of fields that can contain many sort of instances of itself, still maintaining an overall type and rules, but not always having the exact same number/instances of the field. I would love to have this as well.
If that’s not what you meant by “high friction”, then I - like webinit - am curious for further details.
Yep, 100% agree.
So that’s a cool solution, to be sure. But I would very much shy away from this myself because what is the reason to have an entire separate DB just for emails, aside from it allows you to make an arbitrary number of Relation links and thus gets around the field limit issues I referenced above? I may be missing something, but for me this is a great example of the clunkiness and “heavy” solutions Fibery ends up creating for what are otherwise very simple things if you have dedicated functionality for them.
The way I typically think about whether to create a new database for some piece of data or not is this: is there sufficient additional data that relates specifically to that thing that I also want to track? And/or can I move some data off of a parent entity and into this child entity and thus create a cleaner parent. But again the data that’s moved should really be relevant to that child entity.
In this case an email address as its own separate database. What other info do you need to track for “email” as a piece of data? The person it belongs to should be in the parent “Person” type, at least to my mind. What other info would you put there? I guess maybe you could do something like contact history using the Email integration we have now? And then when you e.g. email someone, it goes into some history/comments/activity log for that email address… And while I can see that being useful for some people, I don’t think it should be the only or even default way to create an arbitrary number of email addresses associated with a contact.
One-to-many Relations in List views is also a bit non-ideal from a Contact layout perspective, since we can’t put those relation views in the right area of the Entity view. I suppose Fibery could just add that as an option to solve some problems like this, and it might be a nice option. But I still think there are underlying issues with the “just make a database for this very slightly more complex data” approach. Especially when you combine it with the lack of good tools/capabilities to e.g. move fields around or copy them, merge between types, etc.
I’m curious though if you actually feel like the email-as-DB approach is a really nice solution for your purposes, or if - when you think about it in terms of what would be ideal - perhaps it does look a bit clunky, as I’ve expressed above.
For me @Oshyan, this all seems like over-thinking something that’s really very simple.
A contact can have many email addresses.
That’s a one to many relationship.
I’m not sure why it needs to be more complex than that.
The benefits we receive from this structure are significant and I cannot see any downsides.
A customer emails us from their work email address. That arrives as a support ticket on their contact record. They then lodge another support ticket using a different email address. That arrives neatly as another support ticket on their same contact record. They then place an online order and use their spouses credit card and email address for invoicing purposes. The order arrives neatly on the same contact record. One of their team members orders from their point of sale system using a different email address yet again, it arrive neatly on their contact record.
As soon as a different email address is identified, it’s just updated and the issue of duplicate contacts is solved for the new email address from then onwards.
We have a Fibery report that lists duplicate contact by first and last name. This is checked weekly and all merges are completed. Once completed, it doesn’t need to be re-addressed unless a new email address is used by the contact and then it is solved once and only once.
We have a checkbox on the email database so we can mark as primary one of the email addresses.
We could also have more detail on the email address if we chose, but we don’t have the need right now. For example, we could add to the email database type, “Portal membership access granted”, “Used for billing purposes only”, “Team visible email address”, “Private” etc.
Even though we don’t need this additional information, because we’ve structure the database relationships based on the true statement, “A contact can have many email addresses,” all of these potential future uses are there and ready for us if/when they become required.
I have no idea why anyone would want to have multiple text fields on an entity with Email 1, Email 2, Email 3.
Our setup is elegant and solves a very real issue we’ve experienced in the past when dealing with CRMs. We would continually get duplicate contacts records, over and over again, when a contact would only have two different email addresses, with no way to solve the issue, as the CRM would allow 3 email addresses per contact record, but listed in text fields rather than via a one to many relationship as we have set up in Fibery. We could only set one email address as primary. The other email addresses were used for reference only. As soon as the contact used a second email address, it would create a duplicate contact record with that email address set to primary. We had two options. Either leave the duplicate contacts and have to continuously cross reference orders and communication between them (absolute madness) or merge the contacts, only to have continual duplicates created each time the user toggled between just two different email addresses.
Infusionsoft was one of the CRMs we’d used and this drove us crazy. From the very beginning in setting up Fibery a one to many relationship between contact and email for me was a no brainer. It was like the heavens had opened up.
In terms of the issue of being able to see just one field and then having the option of adding another, that’s exactly what our setup offers. There is just a single email address visible on the contact record. There are no empty fields. If I want to add another one, it’s a single click and the new field appears. We type the email address and create it and now there are two. We can add as many as we need.
I’m still not clear where the lack is in this. It’s Fibery magic. It’s a perfect solution for us.
You’re right, and I think you’ve done a great job of illustrating where in your case and for your needs, Fibery’s depth and flexibility and integrated data model does exactly what you need, and does it very well. But your situation sounds fairly complex, and I do think that generally speaking Fibery needs more ability to better address the simpler or intermediate cases. The email example is probably not the best one to illustrate this (though I still feel like there’s some benefit to a “lighter” field instantiation model like some contact managers have).
In any case it is certainly drifting away from the original example here, which is that reminder-like functionality is fairly clunky in a database, at least the way Fibery currently works. If you disagree with that, perhaps you just feel differently about the UI/UX vs. capability trade-off. There are plenty of people who do, and it’s a very reasonable perspective to have! Tons of people use Org Mode to do everything, which would absolutely drive me crazy. Others just decide to completely program their own tools, and that’s the other extreme of course. But I think the majority of users (i.e. Fibery’s potential customers) tend to want a bit more “ease of use” and “simplicity”. So I recognize your email setup may feel simple to you, and I absolutely see its benefits and have to agree the downsides are small, but I don’t think everyone feels quite that way about it. More importantly, there are other cases where the kinds of “ease of use” or “simpler ways to achieve a goal” that have been talked about here are more needed, I think (again the reminders example, or watcher status, activity notifications, etc).
Thank you for the thorough outline of your system and its benefits though! That is definitely a Fibery strength and I love it for that when I need such capabilities, to be sure.
In relation to the email specific use case, I’m interested to hear @Oshyan what you feel those benefits would be.
I’m interested to hear the downsides also.
I’m probably a little out of place commenting on this thread as I’ve not even read through the reminder app documentation, let alone tried to use it.
We’re still using a reminder set up we created before this came about:
As a business, I wouldn’t be surprised if we have one of the least-tech savvy teams of all Fibery accounts. And Fibery works very well for us.
I agree that ease of use should be a very high priority and the focus should always be on improving that. It’s been said that the ultimate goal of software development is to hide complexity from the user. I think a lot of points about simpler in built (non-fibery like) features have good merit.
Coupled with that, I also feel at times discussion can be blended with a scenario where it’s like someone has been given a missile launcher and their not yet great at using it, or not yet ready for war, so instead of launching into battle, there’s talk about the scratch in the paint that makes the missile launcher not really fit for purpose.
I take the view in our business to just keep on firing. I don’t care if a missile launcher breaks because I have a factory that can build new missile launchers faster than anyone else. They call it Fibery. 
This was a great discussion and I had some follow-up thoughts. However, I’m thinking of posting elsewhere to not hijack this discussion.
I did want to reiterate that Fibery is by far the only tool I’ve found that can do the things that I’ve always dreamed of but never could do. My intent wasn’t to advocate against its inherent flexibility.
Apologies for getting us off-topic!
If it’s not something that you have connected with by now, I doubt I can explain it in a way that will make it “click”. It’s more of an… “experience” thing, and I suspect perhaps a difference in preference around that sort of thing. Because it seems quite likely to be a subjective preference, I can only use subjective words to try to describe it. So, briefly, to me a Relation on a Contact Entity and separate Database “just” for email addresses “feels” “heavy”, “clunky”, “overengineered”, etc. Obviously it is “well engineered” for some use cases like yours, but for others it feels like more than is “necessary”. Meanwhile the subjective experience, even “aesthetic”, of right-side “minimal”/simple fields just feels different than Relations. It’s hard to explain precisely why, but for example there are UI elements in a Relation View that are simply not necessary ever for my use case, e.g. Filter, Sort, etc. Now for you, or others, those capabilities may be awesome! If you have 10+ emails associated with a single contact, heck yeah, it’d be great to have that. But for me I never have more than like 3, probably, and the rare exceptions when I might have more do not justify having the filter/sort features for the other 99% that don’t.
Now you’re probably thinking OK, but can’t you just ignore those “unnecessary” UI elements? Yes, in a practical sense I can. But it still makes the overall UI of the Entity view feel “heavy” and “clunky” to me. It affects how the tool feels to use, for me at least. And this is important, even though I think often in powerful, functional tools like Fibery there is a “functionalism” bias: people want to use tools that “feel” good to them, that work and look in ways that are “aesthetically” pleasing, that feel “smooth”, “uncluttered”, etc. Design matters. And this, ultimately, is a “design matter”. 
Put simply: if you were designing an email field just for the purposes of handling what is necessary for emails (multiple emails included), you probably would not do everything that a Relation field does, simply by virtue of the fact that Relations have to handle a wide variety of use cases.
Now I’m not suggesting that Fibery implement bespoke solutions to everything, or even necessarily to common things like email, but I am very interested in the idea of more intermediate building blocks that can be used for “lighter” representations of data, for example. Rather than thinking about this as “what would be a good way to represent multiple emails that is not as complicated as a full databases?”, instead think about what other kinds of data might benefit from a “lighter” but still more flexible/expandable way of representing multiple pieces of similar data. What I really want is something in-between a single field and a full database. Discussions of in-line ad-hoc calculations and fields fall into a similar category, I think…
This might be too tangential, but it reminds me of some thoughts I’ve had around a “continuum of data representation”, the idea being in part that being able to represent the same “data” in multiple ways can have unique value. Each representation has value that the other ones don’t necessarily have and can’t necessarily replicate, and part of that value for some representations is in simplicity, aesthetics, “cleanliness”. More of my thoughts on that here:
That’s interesting, and perhaps it just suggests that “tech savvy” isn’t the dividing factor here. Maybe “tolerance for clutter” or just differing “design aesthetic” is, I don’t really know. All I do know is that some of the ways that are necessary in Fibery to implement what are otherwise very simple (seeming) functions in some other tools do ultimately feel very, well, “heavy”, “clunky”, “overengineered”, etc. to me. There are those words again, I wish I had better ones, but that’s the best I can do at the moment.
Having followed this discussion without posting myself, I figured it was time to chip in
@cannibalflea 's original comment about contact management
seems to me to fundamentally be a request that Fibery should allow fields that function as arrays of primitive data types (in this case phone or email).
Now, a relation to a database is technically not much different, but there are reasons why @webinit 's solution is too ‘heavy’ for a lot of users, specifically:
The way I see it, if the following features were implemented, the current platform could be made to emulate a basic ‘array’ field type:
With those implemented, the UX/UI then needs to be designed so that creating a (one-to-many) relation to a new (hidden ‘child’) database (with any field as the ‘primary’ field) should be as easy as creating a simple field (e.g. number, url, date, multi-select).
From the point of view of the user, it is an ‘array’ field.
Thank you for jumping in with your deeper understanding and a much better articulation of some of the tangible challenges here and some very clear and I think simple ways of potentially addressing these needs! I am hopeful that invoking terms like “array”, which have a familiar use and context, might help everyone see the potential value here (i.e. this is akin to a type of data model that other systems have had and found value in for decades).
I also want to point out the interesting reality that there is currently a sort of hidden psuedo-array/database model where things like multi-selects are a sort of DB, yet most people don’t know this or how to interact with it. Perhaps a set of options like you describe could help not only to bridge the gap between normal fields and databases, but also bring these existing arrays/psuedo-databases out of the “dark” and into a more accessible UI/UX model?
That would also suggest, I think, at least one addition to your list of basic features to implement this: an ability to “hide” these “databases”/arrays from the various database views, by default (and have an option to display/list/edit them, if desired). Places to potentially hide them from would include, I think, the Database list, as well as the Map view(s). It should not be hard to get them to show up, I just think it should be possible to hide them and persist that, to reduce clutter.
I would also argue that moving toward an approach where databases do not require a “Name” field, but instead just rely on (and expose!) the underlying Entity ID, would ultimately support what you’re describing even better. Already there have been concerns expressed here about the Name Field requirement, I think. And I see no functional reason to require it. It could be a default field, but it should be deletable IMO. I’d love to hear arguments against this if there are important reasons why it’s a bad idea.
In general I love your way of thinking here. Thanks again for bringing some specificity to the murky waters here.
I am totally guessing here, but I suspect when the technical backbone of Fibery was being developed, it was reasonably concluded that when an entity was to visualised then there needed to be (at least) one piece of information shown, and the easiest way to guarantee that is to make one field mandatory and then use that field.
Of course, in almost all contexts (cards, lists, relation views) Fibery now allows the visible fields to be configurable, so perhaps a name field is no longer required 
I think you’ve spelled it out really well @Chr1sG.
I don’t feel we’d gain too much benefit from it, as it’s not been an issue for us, but what you’ve proposed with arrays sounds like a solid solution to that part of what’s being requested.
To clarify, when I say I wouldn’t be surprised if we have one of the least tech savvy teams, I’m referring to the end users, not the backend set up.
I just recorded a quick video for anyone who might be interested in taking a look at a portion of our setup. We have many scenarios inside Make. I’ve chosen the scenario that triggers when someone places an order, as it’s one of the more interesting ones for anyone is interested:
Wow! Very impressive 
I’ll second Chris: wow! Impressive indeed. I’m not sure it was useful for me to watch that at this point, but it was definitely fun and cool to see. I’m a big fan of Make/Integromat as well, even though I don’t use it that much (and not nearly to the level you do!). And I think sharing cool bits of our workflow is definitely worthwhile. Thanks!
