Why You Barely Write Loops to Process a List in Formula

Coming from LotusScript/Java, you'd loop over a list. But formula has almost no loops — because one formula already operates on a whole list at once. This piece treats formula as a functional list language: an operation on a multi-value field runs element-wise (implicit map), @Transform is the explicit map (with @Nothing for filter, a returned list for flatMap), @Explode/@Implode split and join, and @Sort sorts (with [CUSTOMSORT] using $A/$B). What's a ten-line loop elsewhere is often one line of formula. Part two of the Formula @function series.

Reading Values Across Views and Databases in Formula: @DbColumn and @DbLookup

To read another view or another database from formula, two functions do ninety percent of the work: @DbColumn grabs a whole column (keyword lists, dropdowns), @DbLookup finds a value by key (resolve a code to a label, pull a related field). This piece covers both signatures, the cache keyword (""/NoCache/ReCache), and the rules you must know — the first column must be sorted, equality-only matching, the 64KB cap, and where they can't be used. Part one of the Formula @function series.

The Domino REST API Before Go-Live: the Security Model, One-Way Rich Text, CORS, and Admin Ports

Series finale. You can authenticate, expose a scope, CRUD, and query; before handing it to real users, a Domino developer must be sure of two things: does it bypass my Readers-field security, and what will bite in production? The answers: DRAPI is layered security (JWT + scope + Domino's own ACL/Readers underneath), so it doesn't leak — but there are real limits (rich text is one-way out, unconfigured fields are unreachable, same-name forms/views are ambiguous), plus CORS and the admin ports to close before going live. Part six (final) of the DRAPI series.

Your DQL Is Correct but Returns Nothing? The Form Is Missing a dql Mode

Last part fetched a single document by unid. What you usually want is 'the batch that matches' — all incomplete todos, all customers in a region. DRAPI gives two paths: GET /lists/{view} to read a view/folder, or POST /query to run DQL. DQL even supports parameterized queries (?VAR + variables, injection-safe). But there's a trap that follows from the last part's modes: a form without a dql mode is completely invisible to DQL. This part covers both query paths, pagination, the mode trap, and DQL access control. Part five of the DRAPI series.

Creating a Document in the Domino REST API: Why It Needs a Form Field and a dataSource

The door is open (schema + scope); this part does the real work: create/read/update/delete NSF documents over REST. Create is POST /document with a required Form field in the body, and the response @meta carries a unid; read is GET /document/{unid}/{mode}. Every CRUD call carries dataSource — and that value is the scope name you made last part. It also covers two things that give Domino developers pause: why the Form field is required, and what a mode is. Part four of the DRAPI series.

Scopes and Schemas in the Domino REST API: How an NSF Becomes REST Endpoints (Exposing Nothing by Default)

Putting an NSF on REST isn't flipping a switch that exposes everything. DRAPI is secure-by-default: you write a schema (a whitelist of which forms, views, folders, agents, and fields go out), then create a scope (the REST mapping that activates it). A scope's name is the very name the JWT scopes claim recognizes from the last part — and underneath, Domino's ACL and Readers fields still apply. This piece separates schema from scope. Part three of the DRAPI series.

Getting 401s from the Domino REST API? Understand Its JWT Authentication and Scopes First

Almost every DRAPI call has to prove who you are. It doesn't use classic session/LTPA — it uses a JWT bearer token: POST to /api/v1/auth with Domino credentials for a token, then send it in the Authorization header on every request. This piece covers logging in for a token, what the scopes/aud claims control, where tokens come from (Domino-signed JWT, external OIDC, idpcat.nsf), and traps like the signing key changing on restart. Part two of the DRAPI series.

Getting Started with the Domino REST API: Turn NSF Data into Endpoints Any Language Can Call

You want a modern front end, a Python service, or a Power Automate flow to read and write Domino data. The classic answers — XPages, DIIOP, a hand-rolled LotusScript web agent spitting JSON — all make the caller meet Domino on its terms. The Domino REST API (DRAPI, the KEEP project) flips it: a standard REST/JSON layer over your NSF that anything speaking HTTP can call. This is part one of a DRAPI series — what it is, how it differs from classic access, the three building blocks (scope/schema, JWT, OpenAPI/Swagger), and how to start.

A Cross-DB Embedded View Won't Start in the Test Region? It's the Replica ID Baked into the DXL

A cross-database embedded view on a form worked fine in dev, then showed 'cannot start' the moment it reached the customer's test region. Nowhere in Designer's embedded-view UI is there a field to change the source database. Export the form to DXL and the reason shows up: the embeddedview element pins its source by the source database's replica ID — change environments and that ID no longer resolves. This is a field report: how to diagnose it, how to swap it in bulk with a NotesDXLExporter/Importer agent, and the faster way I found afterward — editing the DXL directly in Designer.