Create documentAdd a document to a collection. Leave the id empty and Firestore mints one, which spreads writes evenly across the database; a counting id such as user1, user2 concentrates them on one part of it and slows everything down. Fields are ordinary JSON - text, numbers, true/false, null, lists and nested objects - and the four $-prefixed wrappers reach the types JSON has no syntax for: $timestamp, $geopoint, $reference and $bytes.
Get documentRead one document by its path, such as users/alice. The path from any earlier Firestore step works as it stands, and so does the full projects/... resource name Firestore shows in the console. Ask for only the fields you need to keep a large document out of the workflow. Numbers come back as numbers: Firestore sends integers as strings on the wire, and they are converted back so a later step can compare them arithmetically.
Update documentChange some fields on a document that already exists, leaving every other field alone, and fail rather than create one if the path is wrong. This is the action to reach for by default: Firestore's underlying write replaces the whole document unless it is told exactly which fields to touch, so a plain 'update' elsewhere can silently wipe everything you did not mention. A dot means a nested field, so address.city writes inside the address object and leaves the rest of it intact.
Create or update documentWrite a document at a path you choose, creating it if it is not there. Choose Merge to keep any field you have not listed, or Replace to leave the document holding exactly what you sent and nothing else. The choice is explicit because the two are a single character apart in the API and quietly destroy different things.
Delete documentDelete one document. Firestore treats deleting a document that is not there as a success, so there is a switch to fail instead when you would rather hear about a path that matched nothing. Subcollections under the document survive it - Firestore does not cascade - so empty those by naming their own path.
List documentsList the documents in a collection, a page at a time, with an optional sort. The token from one run continues from where it stopped, so a loop can walk a collection larger than one step should hold. Use Query documents instead when you want to filter.
Query documentsFind the documents in a collection matching one or more field filters - equals, not equals, the four comparisons, in, not in, array-contains and array-contains-any - combined with AND or OR, plus the four operators that test a field on its own for null or not-a-number. Turn on subcollections to search every collection of that name anywhere in the database at once, which is how you read every 'comments' subcollection under every post in a single step.
Count documentsCount the documents matching a filter without reading them. Firestore bills an aggregation at a fraction of what the same query would cost, so this is the cheap way to ask how many - a queue depth, a daily total, a check that something exists before doing the expensive thing.
Total or average a fieldAdd up or average a numeric field across the matching documents, server-side, without reading any of them into the workflow. Documents where the field is missing or is not a number are skipped rather than counted as zero.
Get several documentsRead a list of documents by path in one round trip instead of one step each. Paths that matched nothing come back in a separate 'missing' list rather than failing the step, so a workflow reading a list of ids can tell which of them exist and carry on.
List collectionsList the collections at the top of the database, or the subcollections under one document. Firestore has no schema to inspect, so this is how a workflow discovers what is actually there - and how you find the subcollections hanging off a document before deciding what to clean up.
Increment a fieldAdd to a number stored on a document, atomically, without reading it first. Two workflows incrementing the same counter at the same moment cannot lose each other's change the way reading and writing back would. Negative amounts subtract, a field that does not exist yet starts from zero, and the value after the write is returned so nothing has to read it back.
Add to an array fieldAdd values to an array on a document, skipping any already present. Because it is a union rather than an append, running the same step twice does not duplicate an entry - which is what makes it safe on a workflow that might be retried.
Remove from an array fieldRemove every occurrence of the given values from an array on a document, atomically, without reading the array in and writing it back.
Stamp a field with the server timeSet a field to the moment Firestore applies the write, using Firestore's clock rather than the machine running the workflow. That is what makes timestamps written by different workflows, on different machines, comparable to each other.
Create several documentsCreate a list of documents in one collection as a single atomic commit - up to 500 at once. Either every one lands or none does, and it refuses rather than overwrites if an id is already taken, so a re-run cannot quietly replace someone else's document.
Delete several documentsDelete a list of documents by path in one atomic commit, up to 500 at a time.
Empty a collectionDelete the documents in a collection, in batches, up to a limit you set. Firestore has no drop-collection call - a collection is only the documents in it - so this reads the ids and deletes them. It deliberately does not recurse into subcollections, which outlive the documents above them and would otherwise be orphaned where nothing would ever list them again. If it reports that it stopped at the limit, run it again.
List databasesList the Firestore databases in the connected project, with each one's location, edition and delete protection. Most projects have exactly one, called (default), but a workflow that writes to a named database can check it is pointed at the right one.
Get database settingsRead one database's location, edition, concurrency mode, delete protection and point-in-time recovery setting. Useful as a connection health check: it is the cheapest call that proves the credentials work and the database exists.