atomicdata-dev
Usecase - CRM
CRMs add a lot of value to organizations. Some of them have become the software backbone of the largest organizations. Being able to track leads throughout the entire sales funnel (from advertisements to website to sales call to customer support) is very powerful - having all this information in one place can help provide better support, optimize marketing materials and prioritize sales activities.
I've used a bunch of CRM (Customer Relations Management) tools in the past, like PipeDrive, Twenty, Odoo, Hubspot and SalesForce.
I imagine many of these tools having evolved like this:
- Contacts storage / link to organizations
- Activity logging (calls, meetings, notes)
- Pipeline management (kanban)
- Reporting
- Email logging
- Issue / ticketing / support / helpdesk
- Knowledge base / support
- Email marketing (mass e-mails / mailchimp)
Why AtomicServer might be a good fit
- Custom data models. Users want to add custom properties to contacts and create other models too.
- Very good performance (also for custom filters / sorts / queries). Performance is actually an issue in most of the tools I've tried thus far.
- Powerful / fast search
- Good tools for devs (SDK, Rest API, libraries)
- CMS / article / knowledge base management tools
What is missing
- [ ] Domains specific views (contacts with activity list, organizations)
- [ ] Email logging / sending
- [ ] Calendar logging / sync
- [ ] Reporting / aggregations / counts / graphs
- [ ] Roles / granular permissions
How should we model an issue + the items (comments, actions, todos, document) underneath it?
Explicitly linked from the parent
The Issue has an Array of child items, which is updated every time we create or remove one.
This requires a lot of custom logic, as we did in ChatRooms. Don't like that.
Dynamic relational properties
We could add an invertedProperty implementation, which automatically creates an inverted relationship for every new resource. We could use this so Issue children could link to the Issue and therefore the Issue itself is automatically updated.
But this creates weird sitations. What if someone outside creates this relationship, should the database still update the invertedProperty? That means others can spam issues if they know the identifier. We might circumvent this by checking the write rights on the resource linked with invertedProperty. If someone creates a comment in an issue, the comment links to the issue using this invertedproperty. If the creator of the comment has write rights in the parent, the invertedProperty is created in the parent.
I'm not sure whether this should be done in a separate commit by the client, or as a side effect by the server.
No explicit relationships - just a dynamic collection from the View
This is what we currently do with ChatRooms and Tables. The View knows how to query the data so it can construct the children.
This is not great from the perspective of someone who wants to re-use the data. They can't discover the relationship easily from here.
Other ways?
There must be some!