Custom objects. From an empty screen to a working power of attorney register

You start with an empty screen and one question: what does your company record that no off-the-shelf system covers? In a group of companies every management board knows the answer. It is the register of powers of attorney and authorisations: who acts, on behalf of which company, in what scope, up to what amount and until when. The accounting software knows the companies and their contractors, but not the powers of attorney. The CRM knows the clients, but not who may sign a contract with them. The originals sit in a binder, the list sits in a spreadsheet, and nobody can say offhand which powers of attorney have already expired.

Below are the six steps in which such a register is built in Opero. Each one adds a single piece of the platform, and after the last one the register runs in the system rather than in a spreadsheet.

Step one: the module and the custom object

A custom object in Opero is the equivalent of a table. It describes one thing, here a Power of Attorney, and the information you keep about it. You group objects into modules, logical areas of the application with their own navigation, icon and colour. Power of Attorney goes into the “Legal Office” module, next to Incoming Letters.

From the object definition alone Opero generates screens, a record list with filtering, sorting and search, and API access. You need neither a developer nor a separate database.

Step two: the fields

Every piece of information in the register is a field of a given type. You choose from more than 20 types: text, number, amount, date, dictionary choice, reference to another object, file, signature, calculated field. Each type carries validation, so the amount limit field will not accept “a quarter of a million”, and the “valid until” field has to hold an actual date.

• A dictionary instead of free text. The kind of power of attorney – general, generic or specific – is picked from a controlled list, so the register never ends up with five spellings of the same category.

• A reference instead of retyping. You pick the attorney from the users and point to the principal, a company in the group, as a record of another object. A change to the company’s address does not mean correcting every power of attorney.

• A number assigned by the system. A field with a code generated from a pattern and a sequence number gives the record an identifier such as PEŁ/2026/0017 that nobody types by hand.

• Files on the record. The scan of the signed document hangs off the power of attorney it concerns, not off a folder on a shared drive.

Step three: the scope of authority

The scope of authority will not fit into one field. You define it as a subordinate object, a table nested inside the power of attorney record. Every row is a separate entry with its own fields: the act, the amount limit and the manner of representation – alone or jointly with a board member. You model the “one to many” relationship without configuring a database, and you add rows on the power of attorney form.

Step four: the form and the layout

The object describes the data, the form decides what the user sees. You set the range of fields separately for creating, viewing and editing a record. One object can carry several forms: a view for the employee who checks the scope and validity of their own authority, a full edit form for the legal department.

The layout arranges fields into sections and tabs, with no HTML. You version and publish the layout, and if a new version turns out worse than the previous one, you go back to it with a single click.

Step five: a place in the navigation

The register has to be visible somewhere. A menu item leads to the list of powers of attorney, which you filter, sort and search, for example by company or by attorney. A custom page gathers what the legal department starts its day with: powers of attorney expiring this month, requests awaiting review and a shortcut to registering a new one.

Step six: the process, the rule and the report

A register with well-defined fields takes on the rest of the platform without being rebuilt. You run each power of attorney as a process with stages and transitions: Request, Legal Review, Active, and finally Expired or Revoked. Entering a stage creates a task assigned to a person or a role, and the work shows up on a kanban board whose columns are the stages. A rule on a schedule runs once a day, finds powers of attorney with 30 days of validity left and notifies the legal department and the attorney. A report shows active powers of attorney by company and those expiring within the next 60 days, and from every value you move to the records behind it. A document template generates the text of the power of attorney from the record’s data.

A change a month later

After a few weeks of use a register usually needs a new field or a different dictionary. You prepare structural changes in a draft version of the schema, check them and only then apply them. Until that moment the live register stays untouched.

Where the system’s role ends

Opero will not design the register for you. Which information is needed, what should be a dictionary and what free text, and who is accountable for data quality is your company’s decision. Nor does the system settle legal questions: the kind and form of a power of attorney and the rules of representation that follow from the court register and the articles of association are set by the legal department. The register organises information about powers of attorney, but it does not replace the signed document. A register moved one to one from a spreadsheet, including the “notes” column, keeps most of the spreadsheet’s flaws.

There are technical limits too. A subordinate object accepts only simple fields, so if a scope row has to point to a contractor or a specific contract, design it as a separate object linked to the parent. Deleting a field erases the data stored in it and requires a separate confirmation.

Six steps sounds like a lot of work. In a demo we go through them live, on a register from your own company, and we usually fit it into one meeting. Tell us which register you want to see first.