When you want to capture something, say with the Clip to Devonthink extension, when you hit the button at the end of the Location field to designate where you want it to go, it now will show a little search field at the top of the list of groups in your databases. You can still navigate along the folder tree to find the group you want, but often I’d find it to be a bit tedious and too often I’d click the wrong group or outside the window and have to start over again. By typing in that little search field, it does a rapid search across the groups as you type and I can quickly get the right group I want with just a few characters. The behavior is similar to the Go > To Group feature. It’s made capture for me much easier when I don’t want something to just go to the Inbox.
Got it. Thanks.
When I first started using DTP I used a naming scheme like yours. I then changed and put the date first yyyy-mm-dd_description_etc. This will by default sort in date order. If you choose to view “All PDFs” you will see a chronological history of all your documents. Just my two-cents.
Sorting by date order is a simple option for any record list (added/created/modified)
We don’t need to prefix the record name with the date
Imagine a receipt from 2018 that you scan in 2025. Added, created, and modified date will be something from 2025. Not necessarily what one would want, imo.
I actually have a use case for this
A script that imports transactions from downloaded bank .csv files
The script preserves the correct transaction date by updating the DT creation date
Been there, done that. Let’s just say that some people like to have the date in their file names. The name column is always visible, and the creation date et al columns always (?) display the time, too.
So, if someone is short(ish) on space and still wants to have “the date” displayed…
I’m using something like “company sortable date whatever”. That groups all documents related to one company and sorts them by date. Not saying that this is the best way, it just suits me. At this moment.
One reason I stopped putting the date at the start of file names was exactly this. If the name column couldn’t be very big, I lost much of the name that told me what it was - I just got a long list of dates followed by a few characters as the rest of the name got cut off.
If I need to preserve the original date (which can be lost on some operations), I tend to put it in comments (as these are available to many apps).
That’s why I use the order I do, as I’m usually more interested in the date order of the same types of things from the same companies.
I also use abbreviations where I can “SM” or “SMcNamara” instead of “Sean McNamara”, for example, and “ATO” instead of “Australian Tax Office”, etc.
I’ve done the creation date change in the past, will likely script it in DEVONthink as I find that very useful.
Sean
One important reason NOT to have multiple databases. When DEVONthink crashes - and it does - you have to go into each DB, open the packet, and delete the file with extension LOCK. And you also have to go into the Library to do the same for the inbox.
Welcome @RachieYW
This should not be necessary to do. You just open the database, press Continue if prompted with a warning, and DEVONthink automatically does a health check on the database.
In about six years, DT has crashed maybe once a year on me. And I never had to manually remove a lock file.
I’ve been using DT since 2009 and I can’t remember the last time it crashed. I, too, have never had to manually remove a lock file.
Thanks, Bluefrog - I’ll try that.
Just to clarify: I had several system crashes of my Mac Studio, solved (so far…) a week ago with a reinstall of the OS. Each time DEVONthink created the lock files.
Then yesterday morning I was surprised and disheartened to see the crash report specifically for DEVONthink. It happened at 8pm - 2 hours after I’d stopped working for the day.
AI had some theories: that DEVONthink may have been carrying out background tasks like syncing or database maintenance, or that it was a system event (sleep, wake, cleanup - though I didn’t have those set), or compatibility issue with other apps.
I’ll keep my eye on it. I am heartened that other users have not had crashes, and hope this will be the last time.
Would you mind saying more about your naming conventions?
@kamransoomro84 – Who do you mean?
You. You mention a bit here but I was wondering if you’d mind elaborating.
Ah, OK. This is going to be long, as I’ll be covering some pretty basic concepts which you may already know about, especially around dates.
I started using this naming scheme within a couple of years of starting my Mac consultancy, so around 2000. I was getting more documents both paper and electronic, I was scanning most paper records, and my mind always tries to find ways to organise things (even if I don’t always succeed in implementation).
I represented my current scheme in my post above as:
[origin {company, person, etc}] [topic/subject] yyyy-mm-dd.[ext]
The only significant change I’ve made over time is the date format at the end, and I’ll detail my progression on dates to provide the rationale on why I ended up where I did.
Before I adopted the basic scheme, If I had dates in the filename (and most files didn’t) I had dates generally in d/m/yy format (Aus standard) (or m/yy for end of month/monthly items), a few had four digit years…I think a few even had yy/mm/dd of all things! I first used yymmdd, then yy-mm-dd, now yyyy-mm-dd (ISO 8601 format).
While having the date in the name may seem redundant because of the Created and Modified dates metadata, I use the “true”/“original” date of (usually as shown in) the document in the filename. Then don’t have to worry about getting the Created and Modified date metadata reflecting the “true” date of the document (or changing even if I do set them), especially when I scan documents.
Using ISO 8601 (or any consistent format that goes year, month, day) allows items with very similar names but from different dates to self sort chronologically when the files are sorted by filename e.g.:
Bank Statement 1999-12-31
Bank Statement 2000-01-31
Bank Statement 2000-02-28
vs (original) yy-mm-dd
Bank Statement 00-01-31
Bank Statement 00-02-28
Bank Statement 99-12-31
vs d/m/y
Bank Statement 28/2/2000
Bank Statement 31/1/2000
Bank Statement 31/12/1999
vs m/d/y
Bank Statement 1/31/2000
Bank Statement 12/31/1999
Bank Statement 2/28/2000
While my intermediate yyyymmdd usage would sort correctly, I decided to use the ISO 8601 standard in the end as it’s widely recognised and supported natively as a date format in may computer programs/systems these days.
OK, that’s yyyy-mm-dd out of the way, so let’s look at the simplest component to explain:
.[ext]
which is, unsurprisingly, the extension of the file.
I pretty well universally use extensions these days – I originally relied on the Mac Creator Codes and Filetypes, but that became infeasible over time with the move to Mac OS X and the decline in support for those codes.
Now, onto the [origin {company, person, etc}]. My use of curly braces may have implied this was a hierarchical element, and, if so, I apologise for the ambiguity. The text in the curly braces is really just the types of info for origin, so origin is really where the document came from or relates to, which might be a company, person, etc.
So, for example, my ISP is Exetel, so I would name documents to/from them as:
Exetel [topic/subject] yyyy-mm-dd.[ext]
I think that [topic/subject] would be pretty self explanatory, but putting everything together, I might have these Exetel-related documents:
Exetel Complaint re Internet speeds 2025-07-23.docx
Exetel Complaint re Internet speeds 2025-07-23.pdf
Exetel Invoice 2025-05-31.pdf
Exetel Invoice 2025-06-30.pdf
That’s the basics, but there are two further habits I’ve gotten into: the initials of the person (invariably family members) the document is meant for or related to, and abbreviations for standard/frequent origins or topics/subjects. These save time entering the filenames and/or further aid in categorising documents. Let’s look at some of those:
Origins: I have many documents from the Australian Taxation Office, which is usually abbreviated in Australia as ATO. So, I use ATO instead of Australian Taxation Office in my filenames. Some other ones are AusPost vs Australia Post, SydWater vs Sydney Water StG vs StGeorge (our bank), and NSyd instead of North Sydney
Family Initials: so SM for me, JR for my wife, usually put immediately after the origin so I can distinguish, for example, tax documents for me vs for my wife, rather than having similar types of documents for both of us clumped together because our initials appear after the topic/subject.
Other people’s names: These usually get shortened to [Initial][Family Name], so Fred Bloggs becomes FBloggs. These are most often origins, but not solely so – a scan of a referral from my Dr, John Smith to my skin cancer specialist Fred Bloggs would have a filename like:
JSmith SM Skin Check Referral FBloggs 2025-07-23.pdf
Other abbreviations: I use some common and some bespoke abbreviations as well. Certificate becomes Cert, but Birth Certificate becomes BCert, Australia becomes Aus, Air Conditioner becomes AC, Insurance becomes Ins, etc.
And that’s pretty well it!
There is one small (OK, not that small) postscript to the description above, my progression over time, and my fallibility.
For example, I’m still working on changing filename dates to all be yyyy-mm-dd. While this may seem extreme, the benefits remain as described above, and some archival documents still have the older formats I used. I’m still finding d/m/yy dates, where the day or month may be one or two digits, as well as yymmdd dates.
Similarly, my placement of family initials and use of some abbreviations hasn’t been consistent over the last 25 years. And, of course, I haven’t always described similar documents from different times in the same way in relation to topic/subject.
The consistency habit can be hard to implement, especially when you have inadequate tools, and reviewing all scanned docs with scanner software-generated names like 20250427_153900_001811.pdf and trying to remember what I might have called similar previous documents can be a pain in the arse. See Also and the Graph in DEVONthink will help in finding material after I scan it even before I’ve renamed the scanned files.
But getting strict in regards to that consistency will save you time in the long run. It becomes almost like muscle memory. It’s now hard for me to type a date in d/m/yy format anywhere. My habit in body copy now is to type dates as 23 July 2025, and in “data” formats/usages like spreadsheets or databases I use ISO 8601, even if I’m sharing those files with others.
As I said above:
That improvement of consistency is only part of why I decided to leap into DEVONthink – I’ve also had a lot of life changes in the last two years, and, as I approach 60, I am honestly contemplating my digital legacy.
While I hoard digital data the way my parents (especially my father) hoarded paper records, I don’t want the experience I had looking for important documents in my parents’ voluminous (and unsorted) paperwork on their passing to just be translated into the digital realm for those I leave behind.
And, of course, I want all the benefits a tool like DEVONthink can bring to me while I am still around as well!
Now, that really is “it”!
Let me know if you have any further questions, if I’ve explained anything badly/ambiguously, etc.
I hope this exposition has been useful.
Sean
My processing of Inbox items is assisted with an Applescript
that generates the consistent filename standard
>naming scheme … [origin {company, person, etc}] [topic/subject] yyyy-mm-dd
My standard is: type [details] yyyy-mm-dd keywords
With keywords being a copy of the assigned tags
I use tags to identify ‘origin {company, person, etc}’
example: Statement 2000-02-28 Vendor-ScotiabankChq
Part of the reason I want to explore more and more of DEVONthink!