The warehouse supervisor opens the list in the morning and sees all balances across Turkey. The risk of shipment to the wrong warehouse arises in the very first second on the screen.
Scope definition determines which branches and warehouses the user will see. A faulty setup produces either excessive visibility or blind spots.
In this article, we explained branch and warehouse scope, default context, list filters, and record behavior.
Table of Contents
What is scope?
Scope is the visibility rule that limits the user's data universe and is separate from the security preference. The role dictates what can be done, while scope dictates what can be seen; the two must work together.
EQLEM is a solution platform; in multi-branch operations, speed and security cannot go hand in hand without this distinction. Showing everything to everyone is not control; it produces noise and wrong shipments.
Scope affects both lists and new records; search results cannot exceed this boundary either. Filtering the list alone is not enough; the record context must also be preserved.
Good scope speeds up the user's work because it cuts through the noise and brings the correct warehouse to the foreground. Poor scope produces either blind spots or incorrect transactions and ruins the report.
We established the organizational tree in the company branch warehouse structure article.
Branch scope
Branch scope determines the documents of which locations the user will see. A store manager typically sees only their own branch.
The regional manager can cover multiple branches. In this case, the default branch must still be clear.
Branch scope also affects current account and order lists. An incorrect branch filter disrupts collection tracking.
An additional branch can be opened for temporary support; it should be closed when the period ends. Permanent broad scope accumulates risk.
We covered the chain structure in the chain store management article.
Warehouse scope
Warehouse scope limits stock visibility and movement slips; balance reading is also subject to the same rule. Incorrect warehouse selection generates sales on non-physical stock and breaks customer promises.
A branch may have multiple warehouses; distinctions such as main warehouse, sales floor, and return warehouse are common. Users should only be given access to warehouses relevant to their work; extras invite errors.
Source and target warehouses must be within scope in transfer slips; otherwise, the record goes to the wrong place. An out-of-scope target must lock the record and give a clear warning to the user.
Scope also applies to the counting screen; a user should not count a warehouse they cannot see, and the count list must be generated accordingly. Otherwise, discrepancies become meaningless and the root cause is lost.
We explained the multi-warehouse model in the multi-warehouse stock management article.
Default scope
Default branch and warehouse are the automatic context for new records. An ambiguous default means a misrouted document.
Defaults should load when the user logs in. Asking for manual selection in every transaction slows down speed.
The default should be changeable, but the change must be visible and logged. Silent changes compromise auditing.
The default warehouse is especially critical for mobile field teams. It is easy to select the wrong warehouse on the road.
We discussed field usage in the field sales team mobile article.
List and filter behavior
Lists should open with the default scope; users should not set up filters every morning. This increases speed and reduces errors.
Out-of-scope records should not appear in the list. Records that are visible but cannot be opened cause confusion.
The manager can create broad, saved views. The operations user works with a narrow view.
Search results must not exceed the scope either. Global search must not bypass authorization.
We covered the list experience in the list filters article.
Record context
Branch and warehouse fields in a new document must not fall outside the scope. Unselectable options prevent errors.
If the warehouse changes on a row-by-row basis, each row must be validated separately. The header may be correct while a row is wrong.
Scope control must also run on imported records. An Excel row must not exceed the authorization.
Warehouse mapping in the existing ERP sync must be compatible with the scope. Incorrect mapping writes the balance to the wrong place.
We listed document line errors in the document line errors article.
Authorization vs. scope
Broad authorization must be balanced with a narrow scope. The user should be able to perform any action, but only within their own warehouse.
Conversely, narrow authorization with a broad scope is also possible; an auditor can view but not modify. This combination is frequently used.
When sensitive financial authorization is combined with a multi-branch scope, the risk increases. Do not pile these two into the same role.
Scope changes must be audited just like authorization changes. Silent expansion is a silent data leak.
We established the authorization model in the role-based authorization article.
Multi-company structures
Company scope is the upper layer of branch and warehouse scope. First company, then branch, then warehouse is selected.
The same warehouse name may exist in different companies; the context must not get mixed up. Codes must be kept unique within the company.
A holding company user can view consolidated data, but a single company context must be mandatory when writing records. Ambiguity at the time of writing is unacceptable.
If each company has a different existing ERP, sync mappings must also be set up separately. A single mapping table is not enough.
Multi-company multi-company structure we explained in the article.
Common mistakes
Opening all warehouses to everyone is the most common mistake. Easy setup leads to costly shipping errors.
Leaving the default warehouse blank is the second mistake. The user selects a random one on every entry.
Failing to filter the list and check the record context is the third mistake. The user can still select a warehouse they don't see in the list.
Forgetting to revoke temporary broad access is the fourth mistake. Support ends, the permission remains.
Warehouse location warehouse groups and location clarify with the article.
Setup steps
First, clearly define the branch and warehouse tree. Then, assign a default scope to each role.
Test the list, new record, and transfer scenarios with a test user. All three must validate the scope.
Check the existing ERP warehouse mapping along with the scope. Incorrect mapping breaks the sync.
Scan incorrect warehouse records daily during the first week. Early correction establishes the habit.
Sync plan how to plan ERP sync connect with the article.
Frequently asked questions
Are scope and permission the same thing?
No, permission manages the action, while scope manages visibility. The two must work together.
Can a user view multiple warehouses?
Yes, but the default warehouse must be clear and the justification must be documented in writing.
Does a list filter substitute for scope?
No, it does not; a filter is for convenience, while scope is a security rule.
How are existing ERP warehouses connected?
They are connected via a mapping table; the platform must align with the warehouse codes in your existing ERP system.
Branch and warehouse scope is the invisible backbone of multi-location operations. A flawed setup results in misdirected shipments and inaccurate reports.
Clarify the default context; check the list and record fields together. Do not rely solely on the filter.
Balance permissions with scope; broad permissions work best with a narrow scope.
Tie temporary expansions to a time limit and close them when expired.
Test your existing ERP warehouse mapping along with your scope rules.
By consulting with the EQLEM team, you can finalize your scoping model together.