Is Coda appropriate for wide/deep case/project management?

1

Looking at Coda for an alternative to practice management software, such as Neos, Filevine or Casepeer. An example of Neos is here:
[https://youtu.be/6dQLDqxd8sg?si=nVRia4ys0MZmrmD8&t=292](Example of Neos intake)

What makes this unique is that there will be a ton of single use fields, like Date of Incident, location of incident, injuries, etc. But then there will be a lot of multi-use fields that require subtables, like Insurance policies and related info and docs, all treating doctors, court filings info, hearings and all related info, etc.
So potentially, we’re talking 200-300 single use fields, and then all the related subtables.

Then a checklist of tasks that is about 100-200 deep, with it’s own subtable.

The main base table will be the Cases. There will be a contacts subtable, which will be linked to many of the other tables and subtables, as it will house each client, staff member, vendor, insurance company, medical provider, etc. I thought about different contacts subtable for each type, but they mostly collect the same info.

Wondering if this is feasible in Coda? Another option I was going to explore since the width (in terms of rows) of info is so wide, breaking the single use fields up into groups, with each group being its own table, limited to 1 row per project.

But then viewing it seems weird, as a requirement would be to view 1 case at a time. For example, Once I select John Nguyen vs. Jane Do, I could proceed to other sections without having to again select John Nguyen vs. Jane Do.

If that makes sense.

1 Like
2

:waving_hand: @JD_Ang

welcome to the community! :hugs:

your use case is very achievable in coda :slight_smile:

because there is quite a number of fields, i would suggest utilizing the “Detail” view with non-native stylings as demonstrated by @Andrew_Farnsworth here.

Another option I was going to explore since the width (in terms of rows) of info is so wide, breaking the single use fields up into groups, with each group being its own table, limited to 1 row per project.

are these fields related? e.g. car model and make or are they related to the incident?
if the latter - i would advise not to go down this path.. it will get unwieldy fast. If anything, still put the groups of fields in same table (main one i.e .cases) and then create a view for each group and open up a modal to fill in the group.

hope this makes sense and hope this helps!

cheers!
Mel

2 Likes
3

Because Coda is so flexible and powerful, it is ideal for this use-case.

It is an excellent platform for building customized automations for Project Management, Program Management, Case Management and Contract Management workflows.

The big advantage Coda has over off-the-shelf solutions is the ability to build solutions that codify your company’s propriety methologies and magic sauce.

With off-the-shelf software, you must tailor your processes to match the processes supported by the tool. With Coda, you can build EXACTLY what you need to harness your company’s specialized procedures, methods, policies, and tricks.

But the price you pay for that is the need to do the building and maintaining of those automations.

Thankfuly, Coda is the VERY BEST tool we have found for doing that WITHOUT having to be a developer or database expert.

Keep us posted on your progress, and ask here help along the way.

Max

2 Likes
4

As someone who has been using coda for this purpose and is now moving on to another custom build, I’m going to say no, it’s not good for this.

The tables will very quickly become extremely slow, you can’t use the api if your doc exceeeds 125 mb, and if you have a lot of cases that are “open” at any given time, you won’t be able to archive rows to free up space.

1 Like
5

this is true.

but we overcome this by having several documents.

sometimes we use separate docs per business area, sometimes we create a doc for each program. mostly we use separate docs for each department and use cross-doc or external storage solutions.

we also have strict archival processes, to keep row counts low and relevent to current active cases.

but the point is valid, without strategies to keep row-counts within certain limits, things can get slow. but we usually find ways to overcome this using performance analysis tools in coda.

poor performance is almost always due to a lack of rigor in the design of formulas.

but the good news is that serious engineering effort is being put into overcoming this in coda.

Max

3 Likes
6

:waving_hand: @AJM

curious as to what other custom build you are moving on to ?

cheers!
Mel

2 Likes
7

did you consider to wait or the 1Mil row table (expected before the end of the year)
like Max I am a fan of the distribution of data over various docs
cheers, christiaan

2 Likes
8

@JD_Ang

This sounds like medical cases? If you are in the USA, please remember about about HIPAA confidentiality requirements.

P

1 Like
9

For a case management platform such as the one described above, it’s just not possible to split everything over many docs. That’s doubly true when the cross doc limit is 10k row, the api is limited to docs under 125 mb, and there are many table relations.

1 Like
10

I hired an engineering team and they are building us a custom platform, not using a low code tool.

1 Like
11

No, I can’t wait any longer because my docs are already freezing and causing problems every day.

1 Like