The complete module page

Company Map: everything in your system and how each piece connects to the rest

Classes, graduates, contracts, installments, events, tickets, tables, galleries, employees and suppliers in one navigable map, read from the modules' own tables the moment you open the screen. Search by name, CPF or number, click, and see everything connected to that record in any direction. Compare classes side by side, see which ones need attention, find duplicate records and check an entire list of CPFs at once.

Four screens, zero setup and no data copies. This page is the full reference for the module: the eleven things that go into the map, the thirteen connections between them, the nine attention points, the navigation limits and the reason behind each one, the engineering decisions that explain how the explorer behaves, and the glossary.

  • 11record types on the map, from company to supplier
  • 13connections between them, each one written out in both directions
  • 4screens: map, explorer, compare classes and check a list
  • 0dedicated tables, collection jobs to schedule or fields to configure

Inside the module

8 screens, in the order the work happens

The module has four screens. The map answers what this company has, what is waiting on someone and where to start. The explorer answers what is connected to this record and how it reaches that other one. The comparison answers which class needs attention first. The list check answers which rows of a spreadsheet are already in the system. The rest of this page is what backs up those answers.

01

The four screens

One to get in, one to navigate, one to compare and one to check. There is no first-run wizard and no settings screen.

4 screens
  • Company mapSearch sits at the top because it is the real way in: people arrive holding a name, an email or a CPF, not an internal ID. Below it you see how much of each thing the company has, the proportion between them, the table of how things connect, and lists of recent classes, graduates and events you can click to jump into the explorer. You also get the attention points, duplicate records, export for any list and recently viewed records.
  • ExplorerThe drawing of the connections. Click a record to see what it is, double click to open its neighbors on top of what is already on screen, or open the neighbors of every record of one type at once. Drag to move, scroll to zoom, fit to screen, release what you dragged and save the drawing as a PNG.
  • Compare classesUp to six classes side by side, showing how many of each record and each open issue they have, plus a ranking of every class by attention points. Every number opens the list it came from.
  • Check a listPaste CPFs, CNPJs or emails from a spreadsheet and see, row by row, what is registered, where, what is not, and what shows up in more than one record.
02

What goes into the map

Eleven record types and thirteen connections, declared in code and the same for every company.

2 screens
  • The recordsCompany, class, graduate, contract, installment, event, ticket, table, gallery, employee and supplier. Each one comes from the table of the module that owns it, using that table's primary key as its address. A type whose module does not exist in the database shows up grayed out instead of disappearing: that alone answers why suppliers are not on this company's map.
  • The connectionsClass belongs to company, graduate is in class, contract belongs to class, contract signed by graduate, installment belongs to contract, installment belongs to graduate, event belongs to class, ticket belongs to event, ticket held by graduate, table belongs to event, gallery belongs to class, employee belongs to company and supplier belongs to company. Each one works in both directions and shows its reversed name when you look from the other side.
03

How the map is read

Always live, always scoped to the company, always within a declared limit.

2 screens
  • Live readsThere is no map table. Every screen runs its query against the source module's table the moment you open it, so there is no stale map and no collection job to trigger. The only thing stored is the record count per type, for five minutes, and a button recalculates it on the spot.
  • Navigation limitsSixty neighbors per connection, four hops when searching for a path, fifteen hundred records visited and twelve search results per type. These numbers keep a heavily connected record from tying up the database, and the screen tells you when what you are looking at is a partial view.

The problem and the fix

What changes when connections stop living in people's heads

The pain

How classes, contracts, installments, events and galleries relate to each other only exists in the heads of people who have been there for years.

With Partiu Formatura

The connections are declared in the system and anyone can follow them with a click. Nobody needs to know which screen to look in or which column links one thing to another.

The pain

A question came in about a graduate and answering it meant opening six different screens.

With Partiu Formatura

Search the name, click the result and the explorer brings up that graduate's class, contracts, installments, tickets and galleries on a single screen.

The pain

Nobody can say what will be affected if a wrong record gets fixed.

With Partiu Formatura

The explorer shows everything hanging off that record before the fix, instead of the team finding out from the complaint that comes afterward.

The pain

The visualization tool sent twenty thousand points to the browser and the tab froze.

With Partiu Formatura

The server returns at most sixty neighbors per connection and flags when it cut the list. The drawing grows when you decide, one record at a time, not all at once.

The pain

The reporting module wanted an ontology set up and a collection job scheduled before it would show a single row.

With Partiu Formatura

There is nothing to set up here. A company already using the platform opens the screen and the map is ready, because it is read from the modules the team already fills in every day.

The pain

An old map was showing yesterday's data and nobody noticed.

With Partiu Formatura

There is no copy to go stale. Every time you open it, it queries the source table, and only the count per type is cached for five minutes, with the time it was calculated shown on screen.

The pain

The same graduate was registered twice in the class and got two boletos.

With Partiu Formatura

The duplicate check flags the same CPF or email twice in the same class, the same CNPJ on two suppliers and the same CPF on two employees, with the value masked and a link to each record.

The pain

The graduation committee sent the spreadsheet of who is coming to the party and someone had to look up CPFs one by one.

With Partiu Formatura

The list check takes the pasted list, up to five hundred rows, and returns each one with the matching records and the ones that did not match, ready to export as a spreadsheet.

The pain

With three hundred active classes, nobody knows which one has the most problems piling up.

With Partiu Formatura

The ranking scores every class by attention points, with more weight on overdue installments and upcoming events without tickets, and shows the thirty that need attention first.

How it works

The path information takes, from the module table to the drawing on screen

  1. 1

    You search for some text

    Name, email, CPF or number. The search covers every type the company has and returns results grouped by type, twelve per type. A number is also tried as the record's own ID, because anyone typing 4182 is almost always holding a contract.

  2. 2

    The record becomes an address

    Each result takes the form type and key, like turma:184. That is the record's primary key in the source module, so the explorer link keeps working after any system update and can be sent to a coworker.

  3. 3

    The server builds the neighborhood

    For every connection that type is part of, one query runs in the right direction, with the company filter repeated inside it. A connection whose table or column does not exist in the database is simply skipped.

  4. 4

    The screen draws and keeps adding

    Double click brings in the neighbors and keeps what was already on screen, right where it was. Redrawing on every click would throw everything into new positions and the person would lose the picture they had built.

  5. 5

    The path answers the question

    Pick the destination record and the server looks for a route between the two, hop by hop, up to four hops and fifteen hundred records visited. If it finds nothing within that, it says it stopped at the limit instead of claiming no path exists.

How the system behaves

13 decisions that explain everything else

They explain why the system sometimes does not do what you might expect, and why that is intentional.

Nothing is copied

The previous version of this module wrote nodes and edges to its own tables, fed by scheduled collectors. The result was a map that went stale on its own, a health screen just to watch over the copy, and customers who had to set up an ontology and collection jobs before seeing a single row. Today the SQL reads the source module's table right now. With no copy there is no ingestion, no stale map and nothing to configure.

The model lives in code, not in a table

What exists and how things connect is a decision for the people who write code, in a diff someone else reviews. An arbitrary query stored in the database and executed later is injection with extra steps: anyone who managed to write a row to that table could run anything with the application's credentials.

The company is filtered at every hop

Not just on the starting record. From any record you reach, you can reach everything connected to it, so a single record from another company would open up that company's entire database. That is why the company condition lives inside the SQL of every connection, not just the first query.

A column is a preference, not a guarantee

The schema varies between environments and the module reads tables from a dozen other modules. Label and details declare a list of candidate columns, and the engine uses the first one that actually exists. If none exist, the record shows as Contract 4182. An assumed column turns into Invalid column name in the user's face, and that is exactly how the old module used to break.

Every connection has its own hand-written SQL

There is deliberately no automatic generator based on foreign keys. Half of the real links in this database go through a junction table or a column that is not the key on the other side: the contract stores the user, not the pre-registration, and a ticket reaches its event through eventos_ingressos. A generator would bury those cases behind exceptions, while hand-written SQL keeps each one readable on the line where it lives.

Photos are not map records

A company has millions of photos and no human being navigates a map with a million points. The gallery is the record, and the photo count is one of its details, which is what people actually ask about.

The drawing adds up instead of reloading

Double click brings in the neighbors and keeps what was already on screen, right where it was. Redrawing everything on every click would scatter the records into new positions and the person would lose the picture they had built, which is exactly the work they are there to do.

A missing record and another company's record respond the same way

The difference between the two is exactly what should never be confirmed to an outsider. Both situations return the same response, with the same message.

Only the count is cached

Counting everything on every load is the only expensive part of the screen, and the number does not change minute to minute. It is cached for five minutes per company, with the calculation time on screen and a button to recalculate. The map itself never comes from cache.

A repeated CPF is only a problem within the same class

A graduate enrolling in two classes is normal, and flagging it would fill the list with false problems. The check groups by class, and an employee with a repeated CPF comes with a note that it may be a rehire: the list is for review, and the criteria say what gets included.

The pasted list never travels in the URL

Page URLs end up in browser history, proxy logs and copied conversations. A list of CPFs there would leak to places nobody controls, so the list check arrives by POST and is not saved anywhere.

The ranking queries by issue, not by class

With four hundred classes, asking class by class would mean thousands of counts. The ranking runs one query per issue, grouped by class, and adds up the points on the server. That is what lets a list of three hundred classes come back in seconds.

The screen tells you when you are looking at a partial view

A connection with more than sixty neighbors comes back flagged, and a path search that hits its budget says it stopped at the limit. Without that notice, a partial view looks exactly like a complete answer, and that is when someone makes a decision with half the information.

The boundaries

Where the map reads from

The module never keeps a second copy of anything. It reads what already exists and returns what it produced through the same path as the rest of the platform.

Classes and Graduates

Classes and graduates are the backbone of the map. Nearly every interesting question goes through one of them before reaching a contract, an event or a gallery.

Finance and Billing

Contracts and installments come in connected to the class and the graduate. That view is what answers which graduate paid what, and under which contract.

Events and Tickets

Events, tickets and tables come in with their connections to the class and the graduate, so you can go from a guest to the contract without opening a single report.

Galleries and Photos

The gallery comes in as a record, connected to the class, with photos counted rather than drawn. One record per file would make the map unusable.

People Management

Employees come in connected to the company, which closes the internal side of the map together with suppliers.

BI and Metrics

The dashboard shows the number; the map shows the connections behind it. When a total gets questioned, walking through the connected records is what turns an argument into a review.

Governance

Who sees what, and what runs without anyone asking

4 separate permissions

The whole module is read-only, so there is a single permission: who can open the map. What each person sees after that is still limited to what they could already see in the source modules.

  • View the mapOpen the company map, search and the explorer. This is the only permission in the module.
  • Session companyThe map is always for the company the person is working in, applied to every query and every hop.
  • No writesNo route writes anything, not even the list check. There is nothing to approve, review or undo in here.
  • No configurationTypes, connections and limits come from code. There is no settings screen for the customer and no migration to apply.

The limits, and the reason behind each one

These are not interface preferences. They are what keeps navigation from a heavily connected record from crawling the whole database while holding the connection pool. All of them are enforced on the server.

  • Neighbors per connection: 60A connection with more than that comes back flagged as cut. Bringing everything would freeze the screen, and nobody would read eight hundred records at once anyway.
  • Hops per path: 4Every hop beyond that multiplies the reach by the average number of connections, and the answer no longer fits in the time of a single request. Four hops already cover the route from a ticket to a contract.
  • Records visited per path: 1,500The search budget. When it runs out, the response says it stopped at the limit, not that the path does not exist. The difference matters to whoever is reading it.
  • Search results per type: 12Search looks through every type at the same time. Twelve per type keeps the list readable and the response time predictable.
  • Records per list on the map: 8The lists of recent classes, graduates and events are there to give you a starting point, not to replace each module's listing screen.
  • Count cache: 5 minutesCounting every record of every type is the only expensive part of the screen. The map itself is always read live, and a button recalculates the count whenever you want.
  • Path search time: 8 secondsWhen time runs out, the response says the search stopped, not that the path does not exist. Try starting from a record closer to the destination.
  • Export: 5,000 rowsThe spreadsheet uses the same query as the list on screen. Beyond that, a notice says how many rows were left out, because a spreadsheet that stops without warning gets read as the whole database.
  • List check: 500 rowsEnough for a party's guest list. Larger lists are checked in batches.
  • Ranking: 30 classesThe ones that need attention first. The detailed comparison covers up to six of them side by side.

In practice

6 everyday situations, from problem to result

01

The phone call about a graduate

The scenario

A mother called asking about her son's status: contract, installments, tickets and the class photos. The support agent would have had to open four screens and make sure they were looking at the right person in each one.

With the system

They searched the name on the map, clicked the result, and the explorer opened the graduate with the class, contracts, installments and tickets connected to him.

The result

The answer came during the same call, with no transfer. The risk of checking the wrong person with the same name dropped too, because everything showed up tied to the same record.

02

The ticket nobody could trace

The scenario

A ticket was flagged for irregular use at the event entrance, and the team needed to know which graduate it came from and whether that person's contract was up to date.

With the system

They opened the ticket in the explorer and traced the path to the class. In three hops the trail showed ticket, graduate, contract and class, with the name of each connection along the way.

The result

The question became a screen to show the coordinator. The path stayed drawn, and the PNG was attached to the incident record.

03

The record fix nobody dared to make

The scenario

A class had been created twice and the operations team knew that fixing it could affect contracts, installments, events and galleries. Nobody could say exactly what.

With the system

They opened the class in the explorer and double clicked to expand two hops, with the drawing collecting everything hanging off it.

The result

The fix was planned with the full list in view instead of by trial and error. What needed reprocessing was identified before, not after the complaint.

04

The graduation committee's guest spreadsheet

The scenario

A class's graduation committee sent the list of CPFs of everyone who confirmed attendance at the party, and the events team needed to know who already had a record and a ticket, and who was not in the database at all.

With the system

The list was pasted into the list check. One screen showed the rows found, with the connected graduate and contract, the ones that appeared in two records and the ones that were nowhere to be found.

The result

The team handled only the exceptions instead of looking up three hundred CPFs one by one, and the result spreadsheet went back to the committee the same day.

05

Starting Monday with the right class

The scenario

The customer service coordinator had two hundred active classes and no way to know where problems were piling up.

With the system

The attention ranking put at the top a class with a string of overdue installments and an event three weeks away with no tickets configured. Comparing it with two other classes from the same college showed the problem was specific to that one.

The result

The week started with the class that needed it, with the numbers in hand for the conversation with the committee.

06

The new customer who opened the screen and saw half of it grayed out

The scenario

A recently onboarded customer opened the map, was surprised to see suppliers, tables and galleries grayed out, and assumed the module was broken.

With the system

The screen explains it: a type shows grayed out when that module does not exist in the database, and the notice at the top says how many types are in that state and why.

The result

The question was settled without opening a ticket. As the modules went into use, the types lit up on their own, with nobody configuring anything.

Glossary

The terms on screen, in plain language

The panel deliberately uses everyday business language. If you came looking for graph theory vocabulary, here is what each term means inside the module.

RecordNode, or vertex
Anything that exists on the map: a class, a graduate, a contract, a gallery. It comes from the table of the module that owns it, with the label and details read from there.
ConnectionEdge
The relationship between two records, with a name and a direction. A graduate is in a class, an installment belongs to a contract, a ticket belongs to an event.
Record addresstype:key
How a record is identified, for example turma:184. It is the primary key in the source module, which is why the link keeps working after any update.
NeighborsAdjacent nodes
Everything directly connected to a record, on either side. It is what double click opens in the explorer.
HopStep
Each step from one connection to the next. From a ticket to its class is three hops: ticket, graduate, class.
PathRoute between two records
The sequence of connections that leads from one record to another, searched hop by hop and capped at four.
CutTruncated
The flag a connection gets when it has more neighbors than the limit. The notice exists so a partial view is not mistaken for the complete list.
Grayed-out typeMissing module
The type stays on screen, without color, when its table does not exist in that database. It is what answers why that thing is not showing on the map.
Root recordCompany
The company is the record everything hangs from, which is why it is not in the where-to-start lists: it shows up on the path of any navigation.
LiveNo copy
Reads happen on the source table at the moment the screen opens. Only the count per type is stored, and only for five minutes.
Attention pointOpen issue
A work question answered by a condition on the records, such as a graduate without a signed contract. The number and the list it opens come from the same condition.
Duplicate recordDuplication
The same document or email in two records where only one should exist. Each check's rule says what counts as a duplicate.
Attention pointsClass score
The sum of a class's open issues, each multiplied by its weight. It is what orders the ranking.

FAQ

The questions that come up when evaluating the module

Do I need to configure anything to get started?

No. There is no first-run setup, no initial registration and no collection job to schedule. A company already using the platform opens the screen and the map is built, because it is read from the modules the team already fills in every day.

Is the map a copy of the database?

No. There is no map table. Every query reads the source module's table the moment you open the screen, and the content keeps living in the module that owns it. The only thing stored is the record count per type, for five minutes.

Do I need a graph database for this to work?

No. The module runs on the same SQL Server as the rest of the platform, using capped hop-by-hop navigation instead of recursive queries. That decision is what made it possible to ship the map without adding a second database to the customer's operation.

Why do some types show grayed out on my screen?

Because that module does not exist in your database. No company uses every module on the platform, and the type stays visible on purpose: that is how the screen answers on its own why suppliers or tables are not on your map. Once the module goes into use, the type lights up without anyone configuring anything.

Can I create my own types and connections?

Not from the screen. The model lives in code and changes through developer review, which is also a security decision: a query stored in a table and later executed by the system would be injection with extra steps. A new connection is a product enhancement request, and it ships for everyone.

What happens when I open a record with thousands of connections?

You get up to sixty neighbors per connection and the response flags that it was cut. The drawing grows when you decide, one record at a time, instead of sending everything to the browser and freezing the tab.

Can one company's data show up on another company's map?

No. Every type declares the condition that ties it to the company, and every connection repeats that condition inside its own SQL. The check is repeated at every hop, because from any record you reach, you can reach everything connected to it.

Does the map merge the duplicate records it finds?

No. It points out the duplicate group with a link to each record, and the fix is made in the source module by someone who knows the case. Automatically merging a graduate enrolled in two classes, or a rehired employee, would erase true information.

Is the list I paste into the list check stored?

No. It is sent to the server only for the lookup, it is not saved and it never goes into the page URL. The result exists only on your screen until you export it or leave.

How does a class earn points in the attention ranking?

Each open issue in the class is worth points based on severity: overdue installments and upcoming events without tickets are worth three, signed contracts without installments and past events without galleries are worth two, and everything else is worth one. The total orders the classes, and every number in the table opens the list that produced it.

Does this replace BI?

No. BI answers how much and when, with the number on screen. The map answers what is connected to what, which is the question that comes up when someone needs to understand a specific case or fix a record without knowing what it will affect.

A map that is ready the day the company opens the screen

We can open the explorer on a slice of your data, walk through a real case from ticket to contract and talk about the rollout path for your operation.