Processes that do not run on goodwill and email

Not necessarily, and that is deliberate. NG One carries the documents that arise inside business processes — the ones with a type, a number, a status, an approval and an accounting effect. Unstructured documentation you need to find by searching its contents is a different job, and the Konis family has DocDot for it: a document management system with OCR on scans, versioning and search over the text inside the file. If you already run DocDot or another DMS, NG One does not push it out: the process document stays in the kernel, while the archival copy and full-text search can stay where they are. NG One also carries its own DMS layer over the kernel — records registry, classification marks, attachment versions, archive book — so the split is a decision you make on merit, not one forced on you by a gap in somebody's scope.

That depends on which signature you mean, and we separate the two rather than hide behind the word. NG One carries both mechanisms. The first is internal electronic approval and a signed decision: it records who signed, when, exactly what they saw and in what capacity, with a hash of the signed version and a signature block on the printout. That is a legally clean mechanism for internal consent and entirely sufficient for an internal decision — approving an overrun, authorising a business trip, confirming a stock count sheet — but it is not a qualified electronic signature, and the system never presents it as one. The second is the qualified signature, which requires the signatory to have sole control of the signing means: it runs through a local agent with a smart card, where the private key never leaves the signatory, or through remote signing at a qualified QTSP provider — together with a qualified corporate seal and timestamp for documents that leave the company. Both run through the same workflow kernel, the same state machine and the same trail. The distinction worth remembering: the legal weight sits in the certificate a document was signed with, not in the software that runs the flow — which is why NG One records and displays, on every signature, the means that produced it.

For everything made of states, transitions, conditions and limits — yes. The document type, its numbering, mandatory fields, states and transitions, approval chains with amount limits and branching, SLA deadlines and escalations, automation rules and print templates are all set in the console, with a config audit recording who changed what and from which value to which. What is not configurable is the logic of a guard or an effect: those are named, written in the code of their own module and covered by tests, and configuration only composes them. That boundary is intentional — an approval flow a user drew in a browser and that never passed a test has no business deciding on a posting.

The electronic archive book keeps categories of documentary material with their retention periods — financial records for twenty years, the general ledger for ten, payslips permanently — and is populated from documents already in the system rather than by re-entry. The transcript for the previous year is generated as a file and filed with the competent archive by 30 April. Once retention lapses, disposal is initiated, and disposal is itself a document with an approval and a trail; a legal hold locks deletion for the duration of a dispute regardless of an expired retention period. Reliable electronic preservation requires a qualified seal and timestamp: NG One binds both to the archived copy and keeps the evidence with it, and a qualified provider issues them — as everywhere that the legal weight rests on a certificate rather than on software.

In My work. The global Task Inbox is a canonical part of the home screen: that is where you see the decisions waiting on you, the exceptions that need attention, and what the system finished on its own in the meantime. This space is the administrative and analytical side of the same mechanism — here you define which document type moves through which states, who approves up to what amount, what the SLA deadline is and who it escalates to. The rule from the Atlas is that every business object has exactly one canonical place in navigation; a task that existed in two places would become two tasks the moment one of them failed to refresh.

They declare the absence and name a stand-in, with a validity period. Tasks in that window go to the stand-in, and the record shows that the decision was taken by the stand-in and under whose authority — delegation does not erase the original approver's name from the trail. Amount limits and segregation of duties stay in force: the stand-in gains no authority beyond their own, so an amount over the limit still climbs to the next level. If nobody responds within the SLA, the task escalates by a rule written in advance rather than by whoever remembers to make a call. Password sharing, which is today's most common answer to this problem, has nothing left to solve here.

An inventory of the flows you run today, and an honest decision about which of them deserve to survive. The technical part is configuration: document types, states and transitions, approval chains with limits, SLA deadlines, escalations and print templates are set in the console and packaged into config sets that move from a test environment into production — no developer, no release. What costs you time is the decisions, not the data entry: who approves up to what amount, where maker-checker sits, which combinations of rights must never meet in one person, how long the SLA runs and who it escalates to. Those decisions already exist in your company — they are simply unwritten today, and this is the exercise that says them out loud for the first time. After go-live, correcting one is not a risk: rules are versioned, so a new version applies from the day it is introduced while documents approved before it keep the reference to the rule they actually passed under.