What are the best practices that you could share working with Knack?
1 Like
That’s a very wide and open question 
Make sure you have your object relationships setup correctly and connected the right way.
Ensure each object only relates to one subject. Give thought to data integrity, data validation to ensure you capture data accurately and sensibly. Make sure the application is simple to use and intuitive.
Consider the worflow and use a gated rule based process to move through the stages.
Build the live application to help steer the user, don’t overwhelm them with dozens of buttons on every page. Use modal pop ups for adding and editing records when inline editing is not required, this keeps the UI cleaner.
Avoid creating repeating pages in the builder for add, edit and views. Link to existing so you only have to change one. Use the Accounts object for application access rather than linking to user roles. If possible avoid adding additional fields to User Roles in case a user changes role as you’ll need to try and duplicate fields and sync.
3 Likes
I’m sorry. I was just asking some random questions here thinking no one would answer it
Thank you for a great response.
I wish I knew them before actually building on Knack.
Right now, I’m trying to step back and think about how should I do things more efficiently.
1 Like
Most of what I wrote applies to any database architecture, a large part of my career was in MS Access and the majority of the notes above apply. These are not necessarily Knack related, with the possible exception of User Roles 
1 Like
Backup, Backup, Backup.
Anytime you’re going to make a major change to the functionality of your app, make a copy of the app and date it so you can always revert back if your changes start causing unwanted results. Same with record importing. If you’re updating records or just adding new records, backup your object so if an import goes wrong you can restore the data. Can’t tell you how many times this has saved me from a big mistake.
1 Like
Hi Carl, this caught my attention. Currently, I have the “accounts” object and a “members” object which, as you know, creates two records for every person. I don’t have a bunch of other roles to define so I thought it would be smart to just use “accounts” instead of “members” to avoid duplication. However, and I might have made a mistake, this didn’t seem to work when I tried to create pages, especially limiting views to the logged-in “member” so I abandoned the idea. The example source is the logged-in “Member”, it seems I couldn’t limit the view to a logged-in “account” but could be my fault.
Based on what you are saying, I need to revist this. Any advice?
Thanks!
1 Like