Lessons · Lesson 5 of 5

What a workspace decides

What a workspace is, what it settles once for everybody in it, and why the two things that shorten a menu should never be confused.

Lesson 5 of 5 · 12 min

Did you know

A workspace holds two kinds of secret and factories reliably protect only one of them. Their own costs and margins are guarded instinctively. The buyer's tech pack, colour standards, prices and forward order book are treated as ordinary working files, because they arrived by email and feel like somebody else's problem. The information security standard disagrees, and the phrasing is the useful part. ISO/IEC 27001, in the Annex A control on classification of information, requires information to be classified according to the organisation's information security needs, based on confidentiality, integrity and availability — and on relevant interested party requirements. That last phrase is what puts the buyer inside your classification decision rather than outside it. A brand's unreleased range, sitting in a factory's workspace, is confidential because the brand needs it to be, not because the factory would suffer if it leaked. In practice, the question to ask before opening an account for anybody is not what they need to do their job. It is whose information they will be able to read, and whether that party would agree they should.

Source: ISO/IEC 27001, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Annex A control on classification of information

Two ways to lose a menu entry

A role decides what one person may reach. Something above the role decides what the factory does at all. The two look identical from a chair, because both of them take entries off the same menu. Telling them apart is what stops a new joiner asking to be given a screen that nobody has.

In Nesrine's second week Mehdi cannot find Material Issue. He has the sourcing role, which is the role that would own it. He is not missing a permission. His factory has told the software it does not run its store here.

What a workspace is

A workspace is one factory in the application: its records, its people and the roles they hold, and the decisions it has settled once for everybody. Every record Nesrine creates belongs to it. Every user who signs in belongs to it. The one login in the list that does not is the supplier, who reaches a separate portal and never the factory application at all.

The settled decisions live behind the single Settings entry, which opens onto a page of grouped cards rather than a long list. There are four groups, and their names are the application's own: Buyers & suppliers, Your factory & team, Costing, quality & rules, and Account & connections.

The page is role-filtered like everything else, and the filtering is worth seeing once. For a planner, a QA lead or a floor supervisor, the whole of Settings is a single card holding a single destination — the language picker. Everything else in it is the Owner's.

The setting that changes everybody's menu

The clearest example of a workspace decision, and the one that answers Mehdi's question, is how much of purchasing the factory runs here. There are three answers, and the labels are the application's:

The factory says	Owner / GM	Merchandiser	Sourcing officer
"The app runs everything"	29	18	12
"The app handles purchasing — my system runs the store"	27	18	11
"The app raises requests only"	26	18	10

The three procurement shapes, and how many menu entries each role is left with

Twenty-nine entries, narrowed twice: first by what the factory has told the app to run, then by what the person's role owns.

Three things in that table are worth reading rather than skimming.

The first is that the middle row removes exactly two entries, Receiving (GRN) and Material Issue, and it removes them for everybody at once. No role can get them back, because it is not a question about roles.

The second is the Merchandiser column. It does not move. Nesrine's eighteen entries are the same under all three answers, because neither receiving nor material issue nor purchase orders was ever in her menu. The same decision costs the sourcing officer two entries and costs her nothing. That is precisely why "I cannot see it and you can" is a bad way to reason about access.

The third is that the choices are not free-form. Receiving and material issue must be on or off together, and the application says why: "the app runs the store, or it doesn't." And receiving cannot be on while purchase orders are off, because "you receive against a purchase order." An incoherent combination is refused with those words. It is not accepted and left to produce a stock figure that only ever grows.

Three more decisions worth knowing on your first day

Numbering. Every kind of record has a prefix, a padding and a next number, and a new company starts from a base: styles at STY-101, orders at ORD-1001, purchase orders at PO-1001, materials at MAT-201. A factory can set its own scheme, and changing one never renumbers what already exists. So ORD-1042 is a name inside one workspace and means nothing outside it. Never quote a code to an outsider without saying whose it is.

Lists and codes. The dropdowns behind the app — currencies, units, sizes, incoterms (the standard delivery terms), countries, defect types — are editable rather than fixed. One property of them matters more than the rest: a record that already stored a value keeps it when the list is renamed or retired. History does not silently rewrite itself when somebody tidies a list.

Sign-off rules. Four flows can require an approval before a step happens: sending a quotation, marking a cost sheet final, issuing a purchase order, and an inspection decision. Three are on out of the box and the fourth is off, on the honest ground that an inspection accept or reject is already an explicit human gate. Purchase-order sign-off carries a threshold of 5,000 by default, so small buying does not queue behind the Owner.

Putting the whole course in one sentence

What you can do in MerchandiserOS on any morning is the meeting point of three things. What your factory has told the application it does. What your role is answerable for. And what state the record in front of you is in. The menu answers the first two. The greyed button answers the third. Nothing else in the application is hidden from you, and everything that is hidden says so.

Check yourselfA new sourcing officer at another factory says Purchase Orders is missing from her menu and asks the Owner to grant it. Name the two possible causes, and say how you would tell them apart in under a minute.Show the answer

Either her role does not include the module, or her factory has turned the module off for everybody. Tell them apart by looking at somebody else. Ask the Owner to open his own sidebar. If Purchase Orders is on his and not on hers, it is a role question and granting is the right conversation. If it is missing from the Owner's too, no role grant will ever produce it, because the factory has chosen "the app raises requests only" and its purchase orders live in its own accounting system. The second case is the one that wastes people's time, because it looks exactly like the first from her chair, and a permission request against it can be granted and still change nothing.

Check yourselfZeramdine's controller wants to change the order prefix from ORD to ZC and asks whether the existing orders will be renumbered. Answer it, and then say what the deeper reason is for the answer.Show the answer

They will not. A numbering scheme sets the prefix, the padding and the next number to issue, so it applies to records created after the change and leaves everything already numbered alone. The deeper reason is that a code is not a description, it is an identity. ORD-1042 has by now been written on a purchase request, quoted in an email to Larkspur, printed on a job card and typed into somebody's spreadsheet, and every one of those references is outside the application's reach. Renumbering would silently break all of them. What the factory gets instead is a set of orders with two prefixes, which looks untidy and is honest. It is also a good argument for settling the numbering scheme in the first week rather than the second year.

Prompt · Settle the decisions that are hard to change later

In the first fortnight of a new workspace, before more than a handful of records exist.

Walk me through the MerchandiserOS workspace decisions that are cheap to make now and expensive to change once records exist, and tell me honestly which ones I can safely leave alone.

I will give you: how many people will sign in and what each of them does; whether my purchase orders, goods receipts and material issues happen in this app or in an accounting or ERP system I already run; the record codes my factory already uses on paper; and roughly how many orders a month I expect.

Start with numbering, because it is the one that hardens fastest. Ask me what my existing paper codes look like, and tell me whether to keep them. Explain what happens to records already numbered when a scheme changes, and use that to tell me how long I have before this decision is effectively permanent.

Then the procurement shape. Ask me who actually raises purchase orders and who records goods arriving, and then tell me which of the three shapes matches what really happens rather than the ambition. Say which menu entries each shape removes and from whom. Warn me specifically about the half-in case: recording goods received here while issuing them in another system produces a stock figure that only ever grows.

Then sign-off. For each approval flow, ask me who in my factory is actually answerable for that decision today, on paper. If nobody is, say that turning on a flow will not create accountability, it will only create a queue.

Then stop, and give me a short list of decisions I should deliberately NOT make yet, with the reason each one is better made after a month of real use.

Two rules. Do not recommend a setting because it is tidier; recommend it because of a specific thing that goes wrong without it. And where a decision depends on a fact about my factory that I have not given you, ask for the fact rather than assuming a typical answer.

AI can make mistakes — check anything you act on.