Tenants, identity, access control, governance and operations — running MDM Studio as a secure, observable platform. About 240 minutes of reading, seven checkpoint quizzes, and the certification exam at the end.
Stuck on a concept? Ask in your own words — answers come from the course material with links to the source lessons. Signed-in learners only; daily limit applies.
Recommended, not required — the exam is open to anyone. If you have not taken Foundations, module 0 covers what this course assumes in about ten minutes.
Haven't taken it? Module 0 — Before you start — the assumed ground covers what this course assumes, in about ten minutes, with a self-check at the end.
Tenants, models, roles and the working model, condensed. Skip it if the Associate material is already familiar.
This module is a recap, not a substitute for the Associate track. If the structure below is already comfortable, go straight to module 1.
One deployment holds many tenants. A tenant holds many models. A model holds domains, each holding entities, each holding attributes defined in the Data Dictionary. Almost everything you administer is scoped somewhere on that ladder, and knowing which rung a thing sits on answers most "who can see this?" questions before you look.
A few things sit deliberately outside a model, because they serve all of them: source connections (a global, encrypted registry), reference data (an org-wide code-set library), users and roles, and the audit trail.
The unit that matters commercially is the golden record — the surviving best version of one real-world thing. Capacity is metered in active golden records, counted once each, per tenant; source rows, cross-references, historical versions, merged-away records and reference code values are not counted. Metered, shown, and never enforced.
A user works inside one working model at a time, chosen in the header. Model-scoped configuration cannot be changed with no model active — that is a guard, not a bug, and it is the first thing to check when a user reports that a save "does nothing".
Changing a model's definition requires checking it out: an exclusive lock so two people cannot redefine the same thing at once. It locks the definition and nothing else — jobs still run, exceptions still resolve, golden records still get edited while a checkout is open. Module 6 of this course covers what that means in practice, and why a forced takeover is the wrong tool for a lock held by someone on leave.
Access is a role → area → action matrix, not a list of pages. The roles are Admin, Developer, Steward, Data Owner, Analyst and Viewer; a person's role decides which areas they reach and which actions they may take within them. Two further layers sit on top and are the subject of module 2: sensitivity clearance (which classified values a person may see) and access groups (which rows they may see at all).
Isolation boundaries, user accounts, directory sign-in and platform recovery.
A tenant is a hard isolation boundary enforced at the data layer: its models, sources, users, rules and golden data are invisible to every other tenant. Tenants carry their own branding (logo, badge colours) and their own directory configuration; users can hold membership in several tenants and pick one at sign-in.
Platform-level superusers administer tenants themselves — create, brand, suspend. Suspension is the kill-switch: a suspended tenant's users cannot sign in and its data serves nothing, without deleting anything. Everything an admin does below this line happens inside one tenant.
User management creates accounts, assigns the six-ladder role (Viewer → Admin), activates and deactivates. Deactivation, not deletion, is the right exit for leavers — their history and audit references stay intact while access stops instantly.
Role assignment is the coarse control; the Access Control matrix and sensitive-data clearances refine it. The discipline that matters: grant the lowest role that does the job, and audit the Admin list ruthlessly — every admin is a person who can change who-can-do-what.
Each tenant can configure Active Directory / LDAP sign-in: server, base DN, an encrypted service account, and a built-in connection test. Users then carry a per-user sign-in method — local password or directory — so a tenant can run mixed while it migrates.
Directory sign-in moves password policy, lockout and MFA to where identity already lives. Keep at least one working local admin per tenant even when AD is enabled: directory outages must not lock the platform's operators out.
Deployments configure a bootstrap admin (environment-driven) that self-heals on every boot: if the account is missing or demoted it is recreated with the configured credentials in the default tenant. This is the lockout-proof recovery path — if every admin is disabled or forgotten, a restart restores one known door.
Operationally that makes the server's environment file a credential store: protect it like one. Pair recovery with the idle sign-out guard (configurable timeout, warning dialog first) so unattended sessions close themselves.
Beyond local accounts and per-tenant AD, MDM Studio speaks the enterprise identity protocols. SCIM 2.0 provisioning (Administration → SCIM Provisioning, admin-only) lets your IdP create, update and deactivate users directly: tokens are hashed, revocable and tenant-scoped, SCIM-provisioned users carry no local password, and removal is a soft deactivation so audit history survives. SAML 2.0 (HTTP-POST binding, RSA-SHA256 signature verification, audience and condition enforcement, replay guard) and OIDC (authorization-code flow with just-in-time provisioning and group→role mapping) cover browser sign-in. Users can enrol self-service TOTP MFA, and an admin-grant request/approve flow exists for elevation.
Two administrator's cautions. First, SAML and OIDC are inactive until configured — with those settings unset, the only sign-in methods available are local accounts and per-tenant AD. Second, validate the profile against your own IdP's metadata on rollout; a documented SAML profile is not the same as a tested federation.
Administration → Active Sessions is the live view: who is signed in right now, from where, on which engine — with the ability to message a user or stop a session remotely. It is the screen you open during an incident, and the one that makes "everyone out of the model, now" an action rather than a phone call.
The permission matrix, sensitive-data clearances, row-level access groups, governed change and the audit trail.
Beyond the role ladder sits the Access Control matrix: per functional area (domains, mappings, golden, users…), it tunes what each role may do. The backend enforces it on every request — the page is a management view of a live permission store, not documentation.
Use it for the exceptions organisations actually have: analysts who may edit report definitions but not data; stewards allowed to run jobs in one deployment and not another. Change it deliberately — matrix edits are audited and take effect immediately.
The Data Access page grants per-user clearances for classified data: a level (up to Confidential or Restricted) scoped to a domain, an entity or a single record, optionally expiring. Below their clearance users see masked values; restricted records vanish entirely for those below the record's level.
Administrators also read the access log here: restrictions, grants and unmasked serves of classified values. Grant to named users for stated reasons with expiry dates — clearance sprawl is the quiet failure mode of any classification system.
With the review bypass off — normal governance protocols — governed changes queue as change requests for review and approval. The header says nothing at all — a plain header is the statement that governance is running. Turn the bypass on from Administration → Deployment Models (the one place that offers it, and the natural state during initialization) and changes apply directly, with no approval step: the header turns amber for everyone in that model and an amber Review bypass ON pill appears, with a Turn off beside it. The chrome speaks only when something has been switched off — so the state you want to leave is always one click from leaving, and the state you want to enter takes a deliberate trip to model admin. Every toggle is confirmed, audited and gated by the model's checkout, so the person changing the governance state provably controls the model.
Admin discipline: the bypass is a phase, not a lifestyle — turn it off when initialization ends, and treat a model that never leaves it as a finding. For production models, add strict pipeline mode: Survive then requires a recorded match run and Publish requires active DQ rules with no open critical exceptions, with an audited Override for genuine emergencies.
Governance is also honest about outcomes. The change-request form states, per artifact type, what approval will actually do: whether approval creates the change automatically (green) or hands it back for a person to finish in its module (amber). A hand-back is a designed outcome, not a failure — the approval is the permission; the module is where the work happens. Two related guards: deleting a mapping set with dependent ingestion jobs refuses and names the jobs — with staged-record and run-log counts — and requires an explicit cascade confirmation; and write-back Update operations can be put behind workflow approval via the Access Control matrix — that switch ships off, so nothing changes until an administrator deliberately turns it on.
The audit trail records who did what, when, to which object — sign-ins, structural changes, governance decisions, sensitive access — with business names rather than raw IDs, clickable event detail and export. Filters by user, action, resource and period make it investigable rather than merely comprehensive.
Make audit review a routine, not an incident response: admins added, review-bypass toggles, strict-mode overrides, clearance grants and mass deletions are the events worth a weekly glance.
Know the search's boundary before you rely on it: it covers username, action, resource type and resource id — the four columns printed in the grid — and deliberately never searches the before/after payloads, because a substring match across payloads would be an unrestricted read of governed values. The response says so itself, reporting which fields it searched.
Administration → Security Posture (admin-only) is a self-assessment of the deployment against SOC 2 and ISO 27001 control areas, producing a downloadable assurance report. Treat it as a structured checklist you own the answers to — it evidences your configuration, it does not certify you.
Administration → Secrets Vault (admin-only) holds the credentials the platform needs — source connection passwords, service accounts — under envelope encryption, with one-click master-key rotation that re-wraps existing secrets without re-typing them. Rotation is the routine this screen exists for: schedule it, and rotate on every operator departure.
One failure mode deserves memorising: if the vault's key configuration is malformed, it is treated as unset — the vault is simply not there, quietly, without an error. After any change to vault configuration, verify that secrets still resolve rather than assuming silence means success. This is the general shape of the platform's riskiest settings: they degrade quietly, so verification is the administrator's job.
Related and separate: Data Access governs who may see classified data; the vault governs the credentials the platform itself uses. Do not manage one on the other's screen.
The Access Control matrix answers what may you do and clearances answer which values may you see. Access groups add the fourth question — which records may you see — as row-level security. An Administration → Access Groups entry lists members and a set of rules, each scoping to a domain, a hierarchy tier, a value hierarchy level, a tree node/subtree, or a single column value.
Composition is fixed and worth memorising: within a group, different kinds AND and the same kind ORs; across groups, the grants union. There are no negative rules — you narrow by not granting. A rule the engine cannot resolve is refused, not dropped, because dropping it would widen the scope silently, and an empty resolved set is enforced as "no rows", never as "all rows".
Two administrator disciplines. Governance is opt-in per domain: a domain does nothing until you arm it (access_governed), so arming is the deliberate, audited switch that turns a set of rules into enforcement — and a good rollout arms in monitor mode first, then strict. And ADMIN sits outside the scope unless a domain sets admin_scoped, the same answer the permission matrix gives, so administrators are not accidentally locked out of the data they govern.
Before you commit a rule or arm a domain, preview it: the editor answers "what would this grant" and "what does this person see" — a count of visible versus total records — so blast radius is known before enforcement, not discovered after. A group that would resolve to nothing is shown as such rather than quietly granting everything.
The rule extends to whole surfaces. A tool a user's role cannot use is not shown — it is removed from navigation and its route redirects to somewhere they can work, rather than rendering an empty page behind a "requires role" banner. And governed documents carry the tenant's own identity: a change record or health assessment is stamped with the tenant's logo and brand, not the product's. Administrators own two levers here — which domains are armed, and who is in which group — and both are audited.
A change request is only as governable as its targeted items — the list of objects the change actually lands on. That list is what the printed change record shows, what an artifact's own page reads when it warns you that an open request already touches it, and what an implementer works through item by item, each ticked implemented on its own.
Items are browsed, not typed. The picker is an objects navigator: the model as a walkable tree, rooted under the active model's name with a MODEL badge — domains, their entities, and beneath each entity its attributes, relationships, DQ rules, match rulesets and survivorship rules — with Standardization, Reference, Integration and Analytics as sibling branches. Searching opens matching branches as a view, and clearing the search restores exactly the folds you had. The administrator's reason to care: a picked object contributes its real id and its live name, so renaming that entity next month leaves the request still pointing at it. A hand-typed label was verified against nothing and pointed at nothing — which is why an object that does not exist yet is added as an explicitly unwired placeholder, wired to the real artifact once it has been built.
Linking, wiring and removing an item are all recorded against the request, each naming the item concerned. Removal is the one to notice: it narrows what an approver is being asked to approve, which makes it the most consequential of the three to record silently — so it is not recorded silently.
The other half is sign-off. The record already carries four names and four timestamps, written by the lifecycle from the signed-in session, with a second copy in the audit trail — so a signature adds no identity and no time. What it adds is an attestation ("I read this and I stand behind it") bound to a fingerprint of the record's facts as they stood at that moment. Re-word the justification and that confirmation reads signed against an earlier version, asking the same person to re-confirm; re-print the same record next week and nothing moves, because the fingerprint is taken over the facts and never over the rendered page. You may confirm only the part you performed; Requested is not signable at all — raising the request is itself the assertion — and a part nobody has confirmed prints awaiting confirmation, because silence and consent must not look the same.
Models as deployable units, engines and health, housekeeping and versioning.
Administration owns the model lifecycle: create, clone, import/export XML, activate, and reset or delete with full-cascade safety. The checkout system serialises structural change; admins can force-take a lock when a holder is unavailable — an audited, break-glass act, not a convenience.
Golden-record thresholds, tier bindings and per-model settings live here too. Keep production models few and named meaningfully; archaeology through seventeen "Copy of Test v2 FINAL" models is an operational cost.
One backend serves up to four engines — SQL Server, PostgreSQL, MySQL, Oracle — with per-session selection at sign-in and self-bootstrapping migrations per engine. Health diagnostics surface per-engine status at sign-in and in the About dialog: reachable, migrated, responding.
Health is the first triage stop: a "database unreachable" banner explains a hundred downstream symptoms. Know your engines' health before believing any other error report.
Housekeeping scans for orphaned metadata and physical residue — staging tables from deleted entities, artifacts of abandoned experiments — and cleans exactly what you select, with cascade safety and a step-by-step report. The database residue inspector shows what exists physically versus what the model claims.
Schedule housekeeping reviews after major redesigns and before storage panics: platforms accrete, and deliberate cleaning beats emergency deletion every time.
The platform carries one SemVer version for frontend and backend together; the About dialog shows it, plus internal component builds, the active engine, capability list and a copyable support summary. A version-mismatch warning appears if frontend and backend drift — deployment's first sanity check.
Operational rhythm: read the release notes that ship with the bundle, deploy the matched pair, verify About and health, and record what changed where your own users will look for it. Boring, repeatable releases are the mark of a well-run platform.
“We shipped a fix” is not an answer to a steward asking why a number they trusted last month reads differently. Where a release alters how something behaves rather than adding something new, say so in your own change record, in the words your users use — the build number belongs in the note to support, not in the note to the business.
Say the version correctly. The SemVer number is the release identity; the frontend and backend build numbers beside it are internal component counters for support diagnostics. "We are on v1.2.0" is a statement about the product; "we are on build 503" is a statement to a support engineer.
Before you upgrade a hub whose pipelines are already running, read the guide's Before you upgrade section: two changes in the current release alter what running pipelines produce. First, per-field mapping transforms (UPPER, LOWER, TRIM, EXPRESSION) now execute in the generated extract SQL — they were previously silently ignored — so a mapping configured long ago can land different values on its next run; nothing already landed is rewritten, and the transform-impact report names every mapping whose output moves. CONCAT and LOOKUP remain non-executing and are refused on save. Second, approved specification versions govern runs: approving a mapping set freezes an immutable version and the runner executes that, not the draft; a set with no approved version keeps running its draft, so on most hubs nothing changes at install time — the spec-impact report names the sets whose drafts have diverged from their approved version, and on those sets the approved version is what runs until someone approves again. Neither change requires action to stay safe; the reports exist so the upgrade is a read, not a gamble.
Four Administration screens answer the questions asked after go-live.
Performance benchmarks the match engine so a slow run becomes a number rather than an opinion. Scale Readiness assesses and certifies whether a deployment is sized for its intended volumes. Both produce evidence you can hand to an infrastructure conversation — and note that neither ships with published throughput figures: the numbers are the ones you measure on your own hardware.
Backup & Restore exports a tenant's modelling backbone — models, domains, entities, attributes, mapping sets, managed values, attribute sources, survivorship, glossary, DQ rulesets and rules — into a versioned JSON archive, on a schedule with retention and an optional object-store sink. Understand what restore does before you need it: it rebuilds the configuration under a new working model with fresh identifiers. It is configuration recovery, not a database point-in-time restore, and it does not bring back golden data. Your database backups remain your database backups.
Moving configuration to another environment is its own screen now — see A3L7, at the end of this module. Same archive format, but with a channel, a dry run and a record on both hubs.
Attachment Storage is the hub's file store, and it is a working screen rather than a meter: every stored file, what still points at it, and open / upload / rename / delete on each one. Two things to carry away. First, the four figures at the top — files, total size, orphans, orphan size — are filters: clicking one shows you the files it counted. Second, and this is the one worth remembering, an orphan is a file nothing points at, not a file whose owner has gone; a stored file has no owner, only referrers. Files arrive from message attachments and from dashboard background images, and a dashboard background is not an attachment row anywhere — it is an address inside the dashboard's own layout. That is why the list of what points at a file and the cleaner are deliberately the same question asked once: a cleaner that knew only about message attachments would call every dashboard background an orphan and delete it, and the picture would fail to a blank space rather than an error. If your deployment grows a new place that can point at a stored file, it has to be taught to this screen, or the cleaner will not know about it either.
And for the platform itself: high-availability templates describe N stateless instances behind a load balancer — with exactly one scheduler owner, because if every host schedules, every schedule fires on every host.
Licensing (admin-only, reached from the profile menu rather than the tab bar) holds a vendor-signed licence key that sets the edition — Community, Professional, Enterprise or Enterprise+ (an Enterprise key carrying a higher record band) — with record, domain and user capacities, permitted engines and a feature list. Three behaviours matter operationally. The design is fail-open: no key, an unreadable key or an expired key drops the deployment to Community rather than bricking it. Seats are enforced at creation time, as are Community's three domains — over the limit returns a payment-required error; domains are unlimited on every paid edition. The mastered-record band is metered and shown but never enforced: the platform will not refuse to master a record because a band is full, and it carries 10% headroom above the band. And feature-level entitlement is only enforced when the deployment opts in — so enforcement is narrower than the edition table suggests. Never plan a commercial conversation on the assumption that a flag is technically blocking anything; check first.
RDM Integration extends reference-data serving with subscriptions and HMAC-signed webhook push, so downstream systems are told about a new release instead of polling for it. RDM Serving, next to it, is the read-only pull API secured with service tokens.
Catalog Integration publishes your domains, entities, attributes and lineage to an external catalog in an Atlas-compatible format — providers are a built-in cost-free catalog, Apache Atlas, Microsoft Purview or Collibra — and pulls back on a schedule with delta import, dry-run preview, no overwriting of populated values, and health digests. Say its name carefully in front of users: this is not the Catalog in Modelling Studio, which is the internal read model over your own metadata. Two products, two hubs, one confusing pair of names.
Promotion moves a model's configuration between environments — dev to UAT, UAT to production — over a channel the receiving hub controls. It is the same engine as Backup & Restore, so the archive formats are interchangeable; what promotion adds is everything that makes writing to somebody else's hub safe.
The receiving hub is in charge, and that is the whole design. It issues the token, it decides which directions it accepts, and it can refuse. A sending hub cannot promote its way into an environment that has not agreed to receive from it. The token is shown once on issue and stored as a hash — a lost token is re-issued, never recovered, and no screen anywhere will show it to you again.
The mark is the gate. A model cannot be sent until somebody marks it a promotion candidate. That is deliberate friction: the mark is a record that a person decided this model is ready to leave the environment, and it shows on the model row.
Direction is derived from the two environments' roles, never typed. dev → prod is uphill and carries the heaviest guards: you type the name of the environment you are writing to, and you record a reason that lands verbatim in both hubs' logs. If you find yourself typing production's name, that is the control working.
Always dry-run. The dry run is where the receiving hub answers everything that can refuse — and the Promote button is not offered until it has. Three refusals are worth knowing before you meet them:
The way back is taken before the way forward. The receiving hub archives everything it currently holds for that model before it changes anything, and lists it under History as a restore point. Restoring one takes its own restore point first — going back and then wanting to go forward again is a real thing that happens at 3am.
What never travels: records, credentials, environment identity, and each person's own display settings on the receiving hub. What does travel and surprises people: sensitivity classifications, with the model backbone, deliberately unstripped — a promoted model must never be less governed than the one it came from. The checklist tells you both, before you tick anything.
Reference data travels — but only the parts that are wholly this model's, and the exception is worth understanding before you plan a release around it. A value hierarchy whose levels reach into another model's domain, or a crosswalk with one end in another model's domain, belongs to two models at once. Promoting it would rewrite the other model's configuration on the receiving hub, and nobody working on that model would be asked. So those stay where they are.
What is left behind is named, every time — and this is the part to teach your team. The dry run lists each hierarchy and crosswalk it is not taking, by name, with the reason, and the same sentence goes into both hubs' logs when the promotion lands. It is a notice, not a refusal: nothing has gone wrong and everything else lands normally. It exists because the alternative is the worst kind of success — a promotion that reports "applied", and something you expected on the far side quietly absent, with no record anywhere of the difference. Months later "why is that hierarchy not on prod" is answered by reading the ledger entry, not by guessing. If you need one of these to travel, give it a home in a single model first.
Two more kinds of configuration travel, each with an edge: fix patterns somebody wrote by hand travel, while the pattern library the product ships does not — the receiving hub re-creates its own on every start, and a promotion carrying them would fight the seeder for ever. Report sources that belong to a model travel; sources describing the receiving hub's own stage tables are that hub's own business and stay put.
And if the two hubs cannot reach each other, download the archive and carry it. The checksum is inside the file, so the receiving hub's checks are identical either way.
The import bridge that ships OFF, and why external-asset writes are audited rather than gated.
Catalog Integration pulls metadata in from an external catalog — Atlas, Purview, Collibra. That metadata can be offered to the external-asset register as steward proposals: register this as an external asset. Two facts an administrator owns.
It proposes; it never registers. Every suggestion waits for an explicit accept, and a rejection is remembered so the same suggestion does not return next week.
And it ships OFF. A deployment that pulls from an external catalog does not start proposing external assets until an administrator deliberately turns the bridge on. This is the product's rule, not an accident of configuration: a capability made possible must not be switched on. If your stewards report that nothing is being proposed, that is the shipped default answering correctly — check the switch before you check for a fault.
Registering, editing and retiring an external asset is written to the audit trail with actor and timestamp, but it does not raise a change request. Editing a catalog facet does. Administrators get asked to defend this asymmetry, so here is the defence: recording that a warehouse exists is documentation, and putting an approval queue in front of documentation is the reliable way to end up with a register nobody updates. A facet, by contrast, asserts who is accountable and what something means — that should be reviewable.
Two operational consequences. External assets are global, carrying no model, so a retire is felt in every model at once — there is no per-model blast radius to reason about, and the link count in the confirm dialog is the whole of it. And because these writes are audited rather than gated, the audit trail is your only after-the-fact control on this surface: it is where "who registered that, and when" is answered. Audit entries cannot be edited or deleted, which is exactly why that works.
Two one-time behaviour changes an operator answers for after the upgrade, and the refusals — caps and blocks — that are features, not faults.
Two recent behaviour changes touch what Publish writes, and both will reach an administrator as the question "why did these values change?". Know them cold.
First: the mastering default. The first time a standardization rule is attached to an eligible attribute on which nobody has yet decided, the master standardized value flag now defaults on — the cleansed value reaches the golden record without a second step. This is one-time per attribute in the only sense that matters: the moment a decision is recorded, the default never touches that attribute again. Three states stay distinguishable forever — undecided, on, off by explicit choice — and a recorded human "off" is never overturned. Attributes that predate the default are offered, never flipped: every switch-on is somebody's previewed, acknowledged decision, because it rewrites published values at the next Publish.
Second: tiers stamp the standardized form. A tier bound to a standardized attribute now groups by the cleansed value — consumer and CONSUMER under one node. Both stamping paths — the pipeline's Publish and the tiers page's Backfill — apply the same rules through the same engine, so a freshly published record and a backfilled one cannot disagree. Where the attribute does not yet master its cleansed value, the surfaces disclose it — "standardized for grouping — stored value is raw" — and the mastering offer is the road out.
When the question arrives, the answer is in the product: the flag's decision record says who and when, the offer's preview said what would change before anyone agreed, and nothing changed for any attribute where a human had already decided.
A family of recent surfaces share one operational law: past a limit, the platform refuses with a reason — it never silently truncates, widens or guesses. An administrator who knows the refusals can tell a healthy limit from a fault in one look.
The pattern to teach your users: a refusal names its reason and its remedy, and the counts you do see remain true. The alternative shapes — a truncated tree drawn as complete, a scoped queue quietly widened, a partial run reported green — each put a false number in front of someone who will repeat it. The refusal is the platform keeping its numbers honest; treat one as information, not an outage.
The three-tier settings model, the account-stored theme, and the difference between locking a definition and freezing a hub.
Some settings shape how the product reads rather than what it does. These resolve in a fixed order: the user's own preference, then the model default, then the system default. Whichever tier answered is shown beside the control, so "why is mine different from yours" is a question the screen answers rather than a support ticket.
The first setting on this mechanism is the filter dropdown threshold — the number of distinct values below which a report or dashboard filter renders as a picker instead of a text box. Zero turns pickers off entirely.
The governance split is the one to expect everywhere this mechanism grows. A person's own value is theirs, open to every role, because gating it would stop a viewer making the product legible to themselves. The model default — what everyone without a personal value gets — is governed, restricted to governance roles and written to the audit trail. A stored value that is corrupt or out of range is treated as absent and falls through to the tier below, so one bad write never blanks a control.
Theme follows the same instinct but is purely personal: light or dark, stored on the account rather than in the browser so it follows the person to any machine, and applied before the first pixel is painted.
The model checkout is a mutex over the model's definition — domains, entities, attributes, relationships, mappings, match and survivorship rules, standardization, jobs and glossary terms. Two people cannot change those at once, and that is its entire purpose.
It is not a lock over the hub. While someone holds a checkout, everyone else can still run ingestion jobs, review match pairs, resolve data-quality exceptions, edit and author golden records, publish reference-data releases and approve governance requests. None of that changes the definition, so none of it is arbitrated by the lock.
Check-in is a review. Checking out snapshots the definition; checking in lists what changed, area by area, each change ticked to commit or unticked to revert to its exact pre-checkout value, in one transaction. Three things the review states rather than assumes: changes approved through governance during the checkout are badged with the request and its approver, and reverting one asks you to confirm you mean to overrule the approval; areas the snapshot could not compare are named, and checked in as they stand; and a change list that failed to load says so rather than claiming there was nothing to review.
For a lock held by someone unavailable, prefer Release over forcing a checkout. Release drops the lock without taking the model over and keeps the absent holder's snapshot, so their pending changes stay reviewable. Forcing a checkout transfers the lock and re-baselines the model — their pending work becomes the new baseline and stops being reviewable at all. Both are audited; only one is recoverable.
MDM Studio Certified Administrator — Exam — 47 questions, 65 minutes, 70% to pass.