Forum Discussion

JayWhite's avatar
JayWhite
Qrew Trainee
5 years ago

Newbie looking for help on the best application architecture for a complex app

Hello, I am very new to Quick Base and playing with the trial.  While under the trial I am most certainly not going to fully develop this app, but my hope is that I can find a platform in a way to make an ERP system for my company.  Basically a hybrid of an architectural firm and contractor in one so we need to manage projects from design through opening day.  Many phases, many deliverables, etc.  One of my goals is to take what is now independent systems and combine into one:

Project Management Software
CRM
Expense Tracking
Communication Tools
File Storage (for project related material) 
Etc.


So my question is do I develop all of this one application or will that be cumbersome?  Should i build a Contact Manager App, an Opportunity Manager App, a Project Management App and share data or build all under one master application?  

The architecture of Quick Base seams to support individual apps, but most people through forum seem to say one big app.

Currently we are 50 employees and expecting to go through a nice growth period.  But we have a long time until we are in the hundreds count (although certainly hope to get their one day!)

Thanks in advance

App builders
Ask about Quickbase functionality
Relationships

10 Replies

Sort By
  • ChayceDuncan2's avatar
    ChayceDuncan2
    Qrew Cadet
    5 years ago
    It's hard to give a blanket answer. Everyone is different in how they want their organization to work. You could certainly build one big app - and you'd be just fine. You could also build a 'hub and spoke' idea, where you have different apps that are all isolated into smaller chunks/specific purposes - and then you use Quick Base syncs or automations to make them all talk to one another so it still acts like one big system. 

    The nice part of one big app is that it's all in one place. No one has to worry about 'where' some information might be or where they have to go for it, its just in one place etc. The backdrop to that is that you have everything going on in one place, so you have to be more careful with development as your changes might have big impacts once you go to production. 

    The advantage of having smaller apps - is that it reduces some of the complexity, especially when it comes to user management. If you think about a true ERP - you'll have 100 people with generic or specific job functions. Since each would be siloed - some people could be in some apps but not others. With one big app - you have to be constantly checking and re-checking permissions - and you end up with a big list of roles to account for people who have abnormal job functions or are kind of floaters and just do a lot of things. 

    Others on this forum may have a different answer, but personally, I would suggest segmenting it all out. The development lifecycle and user management controls of having different apps makes managing everything easier in the long run. Especially if you're planning for growth - going in with the hub-and-spoke mindset will help in later adoption for 'simple' or one-off apps that you can put together quickly that may not be part of your true ERP system, but can make a difference for small teams. If everyone is used to smaller, more specific apps, their adoption is usually better.


    Chayce Duncan | Technical Lead
    (720) 739-1406 | chayceduncan@quandarycg.com
    Quandary Knowledge Base
  • JayWhite's avatar
    JayWhite
    Qrew Trainee
    5 years ago
    Thanks Chayce,

    I really do buy into the simplicity of future development if nothing else.  For example one major component of the app is going to be to maintain a database of contacts, the contact manager.  That seems to me like it would be a fairly simple system to quickly build out and keeping it isolated could be a real benefit.

    I noticed your quick base sync note....  Would I need to sync data or can I just reference tables across apps?  Just wanted to ensure there is no significant performance loss in doing that.  It seems like that would work well on my end but not sure if that creates security issues or otherwise.
    • AustinK's avatar
      AustinK
      Qrew Commander
      5 years ago
      One thing to keep in mind is depending on how you connect your apps it can cause them to actually share the same resources on the system. So while you may have split them out it doesn't matter because using one app will cause the other to run alongside it. Basically it looks like 2 apps but it is one large one.

      There are many different ways to link your apps or the data within them and they all have their pros and cons. Do some research into the different methods and see which one makes the most sense for you. Some of the methods can even block your ability to sandbox an app, if that is important to you then you need to make sure you pick the right method. The link below is a great resource.

      https://community.quickbase.com/quickbase/topics/sharing-data-across-quick-base-apps-part-1-cross-app-relationships-table-to-table-imports-and-sync
    • JayWhite's avatar
      JayWhite
      Qrew Trainee
      5 years ago
      Austin, so I did read this thread and it didnt quite help me all the way through.  The downside of cross application data I can see is managing the security as well as navigation.  I would think a single app is better in that regard.  However, the complexity of developing a single app will certainly be significant.

      Are there any resources to speak to the downsides of a single large application?  We currently have 50 employees so for hte foreseeable future I cannot see us being concerned with 100+ employees.  Of course that could happen one day.  But I am not sure how taxing we really would be on a single application system.  Just not sure how to gauge that.
    • ChayceDuncan2's avatar
      ChayceDuncan2
      Qrew Cadet
      5 years ago
      Jay - to provide more context - Quick Base loads your application when you open it. When you have cross-app relationships - Quick Base also then goes and loads those applications from memory too. So basically if you have 5 connected apps - and you open one - Quick Base sees that and loads all 5 for you regardless of which you opened so it operates in practice kind of like one big app as far as the work Quick base has to perform. So in regards to size and complexity - they're comparable. Based on 50 - 100 users - unless you're loading millions of records across your system - this probably won't be an issue. 

      As for security - it's not really any different whether its in one app or several. You still have full control over what permissions users should or shouldn't have to certain fields/tables etc. As I mentioned before - my experience has been that when everyone is in a single app you end up creating one off roles and overly complicated permission sets to account for specific use cases where different people in similar roles in your company need to do specific / unique things in your system. Think about if you have resource data somewhere. If you break it into its own app - you can only allow certain people to view and manage it in that one app. But if its in the same app - you might have some users who all perform the same daily function - but also have some HR responsibilities and they're the only person on that team who can see the resource data. Things like that necessitate a broader role set in a single application. Certainly not a technical issue - just an annoyance to have to manage a lot of roles.

      You're correct though - navigation can be a little odd if people don't always know where information is stored in some cases if everything isn't in the same app

      Chayce Duncan | Technical Lead
      (720) 739-1406 | chayceduncan@quandarycg.com
      Quandary Knowledge Base
  • QuickBaseCoachD's avatar
    QuickBaseCoachD
    Qrew Captain
    5 years ago
    Another factor to consider is that when the user opens the app they will land on a dashboard. And of course they can only land on one dashboard for a given app. Yes they can have buttons to take them to different dashboards.

    But if you have different apps it does mean that you may have a better opportunity to land users on a relevant dashboard. If you have users which use an app for servers quite different purposes then it�s hard to know what dashboard to land them on.
  • JayWhite's avatar
    JayWhite
    Qrew Trainee
    5 years ago
    Oh wow this is a great point and might point me in another direction.  I do want different users to have different initial views.  So I cannot configure it based on role?  It is based on app?

    For example I want all users to see their tasks throughout the entire system, but I want Project Managers to see Project Status on their home page, Sales team to see sales pipeline and opportunities, designers to see project status for what they are working on etc.

    I cannot create different dashboards based on roles?

    Thanks again for the help, this is really great for getting started!
  • QuickBaseCoachD's avatar
    QuickBaseCoachD
    Qrew Captain
    5 years ago
    You can definitely assign Roles as to which dashboard they land on so that is no problem.

    The point I was making it was that if a user is using an app for multiple quite different purposes then you have to decide which dashboard you�re going to land them on.

    I guess it depends how pigeonholed you�re going to make your Roles. You don�t want to go to crazy on the number of Roles because it stars to make you crazy in assigning which Roles users belong in and maintaining these Roles.

    .Roles come up in dynamic form rules and in permissions so you do not want an app that has 20 Roles.
    • QuickBaseCoachD's avatar
      QuickBaseCoachD
      Qrew Captain
      5 years ago
      Roles also o control which tables the user sees in the table bar.

      Often you try to design apps to not show users tables they need not be concerned with. But in the same way that you assign a user to see a particular dashboard, you also end up assigning a user to see a particular set of table bar icons.

      So when a user is in a job perhaps at a higher level where they are needing to do multiple functions then it becomes impossible to control which table bar icons they will see.

      When it comes to actual permissions, the system looks through all the rules and assigns the user at the most permissions possible.

      But when it comes to The dashboard of course they can only land on one dashboard and similarly they will see the table bar icons for the highest priority role they are assigned to.

      The Roles themselves can be dragged and dropped to sequence their priority and that is how the system desides which dashboard or which set of table icons to show for her user who is in multiple roles.

      The roles themselves can be dragged and dropped to sequence their priority and that is how the system decides which dashboard or which set of table icons to show for a user who is in multiple Roles. .