01/12
The check route
Read the product search alongside the office’s separate review steps.
- 01/08
Why separate searching from acceptance?
Search produces data matches, not a professional suitability decision.
- 02/08
Which people need separate assessment?
The office determines relevant people and organisations; the software does not automatically discover every relationship.
- 03/08
Which records does the product search?
Identifier and name matching uses accessible client records, not the entire case and intake archive.
- 04/08
What do the three result labels mean?
An identifier match, name similarity or no match within scope; none is a legal decision.
- 05/08
Which check information is stored?
Query, result/details, checking user and time; acceptance reasons and deciding lawyer are not separate fields.
- 06/08
How do access boundaries affect results?
Roles and tenant/branch scope limit accessible data; they do not guarantee a complete office review.
- 07/08
How is the review refreshed?
The office evaluates new information and a user runs another check when needed; there is no automatic monitoring.
- 08/08
How does it work on web and mobile?
An authorised user opens the separate form, enters a name or identifier, optionally selects references and views the result/history.
02/12
Two separate searches and office review
Fictional example; it executes no real query or intake conversion. The two parties and matter at the top are an office checklist, not fields of one product form. Each name needs a separate check; the legal decision is separate.
- 01/05
The applicant and opposing party enter a fictional checklist; the software neither discovers relationships nor starts a check from an intake automatically.
- 02/05
An authorised user separately searches each name among accessible clients. The intake/case archive is not automatically searched.
- 03/05
One name has no match within scope; the other produces a name-similarity candidate. No match is not acceptance approval; similar names do not prove identity.
- 04/05
Each check stores its own query, result, checking user and time. No intake link or acceptance/rejection reason is automatically added.
- 05/05
The office separately reviews relevant relationships and sources. Acceptance/rejection, reasons and necessary communication are not automatic outcomes of this search screen.
The office identifies search subjects
03/12
Why separate searching from acceptance?
The office assesses relevant people and earlier relationships for the matter. A written review process helps track sources considered and open questions; it does not itself guarantee legal proof or acceptance suitability.
Use Vekilaw checking as a separate data search within the office acceptance procedure. Creating an intake neither starts it automatically nor attaches results to the intake. The intake guide explains status progression, separate conversion and case-creation boundaries.
04/12
Which people need separate assessment?
Identify the applicant, opposing party and other relevant people/organisations for the matter. A qualified person assesses necessary ownership, representation and earlier-role relationships; the product does not search trade registries, family relationships or previous-role databases.
Run separate checks for individual names or identifiers. Turkish-letter normalisation and name similarity can help with some spelling differences; they do not conclusively resolve company mergers, relationships or personal identity.
- Applicant and relevant people/organisations
- Opposing party and other relevant people
- Earlier relationships and roles identified by the office
05/12
Which records does the product search?
Identifier search looks for a number match in accessible client records. Name search evaluates at most 500 database-selected client candidates. This bound does not mean every record was reviewed in a single check.
Past intakes, case parties, closed-case contents, advisory texts and lawyers’ earlier roles are not automatically searched as additional corpora. Separately review other sources the office considers necessary. A record hidden by tenant/branch scope or access cannot be treated as absent.
- Product corpus: accessible client names and identifiers
- Separate office review: cases, intakes and other sources
- Records outside search scope or access
06/12
What do the three result labels mean?
CatismaVar means a client identifier matched the searched identity/tax number. Name similarity produces PotansiyelCatisma; even an identical-looking name does not establish legal certainty. When both name and identifier are searched, an identifier match keeps result priority.
CatismaYok means the query produced no match within its access and candidate scope. Missing data, candidate bounds or different record corpora mean this is not proof of no conflict across every office relationship. A similarity score is neither a probability of personal identity nor a legal-risk percentage.
The lawyer separately decides acceptance, rejection or additional information. This guide sets no universal rejection condition, exception, consent rule or information-wall cure; assess applicable current professional rules for the matter.
07/12
Which check information is stored?
A check stores the searched name/identifier, result, match details, checking user ID and time. Optional client or case references can be selected at creation. They do not expand the search corpus and are not an intake relationship.
The scoped check history can be read. Acceptance/rejection reasons, deciding lawyer, recheck reminders and a later editable decision/note workflow are not fields in this contract. The office separately manages necessary professional-review evidence with suitable access and retention.
- Searched name or identifier
- Match result and details
- Checking user and time
- Optional client/case reference selected at creation
08/12
How do access boundaries affect results?
Roles and permissions separate reading from check creation. Linked client selection needs client-read permission; linked case selection needs full or assigned-case read access. The server separately evaluates tenant/branch and selected-record eligibility.
Hiding a record from a user does not resolve a legal conflict. An assignee field guarantees neither separate note privacy nor a user-visible history of every read. The office should separately review sharing and access decisions using actual user roles and the matter.
09/12
How is the review refreshed?
Reassess the office review when parties, identifiers, names, representation or matter information changes. The software does not automatically rerun checks, update earlier results or issue legal warnings from those changes.
A new check creates a separate history record. An earlier record does not prove that current access, data or relationship scope was covered. No universal retention period or automatic cleanup is promised for retention or person requests.
- New people/organisations or changed identifiers/names
- New matter or changed relationship scope
- Changed data or access boundaries
10/12
How does it work on web and mobile?
Conflict checking is a separate operation. Web uses a drawer and mobile a new-check screen. At least one name or identity/tax number is required; number format/checksum validation is not official identity-service verification.
Optional client or case references are selected only at creation; existing records and live permissions are checked separately. Creating a check is a write operation requiring appropriate tenant access and permission; history reading is a separate permission.
Web reads, forms and selectors belong to the current session and permissions. Mobile list and creation screens close when another route is opened; old drafts or late responses do not carry into a new session. Cancellation does not prove the server did not apply the request; reread history rather than automatically repeating an uncertain operation. Intake conversion does not require a saved check result, and results are not automatically transferred to an intake.
11/12
What a match looks like
A fictional name search shows accessible client candidates, not case parties, relationships or a legal decision.
- Örnek Yapı A.Ş.Name similarity · Client record
- Örnek Yapı AŞName similarity · Client record
12/12
Frequently asked questions
- 01
Does no match mean I can accept the matter?
No. It describes only a search within access and candidate scope. Relevant relationships and professional suitability need separate assessment.
- 02
Are cases and intake history searched too?
This operation searches accessible client names/identifiers. It does not automatically scan every case, intake or advisory text. An optional record reference does not expand that corpus.
- 03
Does a saved check verify acceptance or identity?
No. Query/result, checking user and time are stored; official identity, legal decisions and reasons require separate review. A checksum is not official verification.
- 04
Is there one fixed retention period for checks?
This guide sets no universal period or automatic erasure rule. The office separately assesses data types, purposes and applicable requirements; an existing history record alone proves no compliance.
Official sources
Official starting points for separate review of applicable current requirements. This product source review is not a new legal verification or approval for a specific matter.
Related guides
- Roles and Permissions in a Law Firm: A GuideCompare illustrative role plans with actual grants; assess assigned-case reads, team/company membership, MFA and audit boundaries separately.Read the guide (8 min)
- Moving your Turkish law firm from Excel to legal softwareSource cleaning, separate import kinds, column mapping, preview and error reports: a controlled migration plan with a pilot.Read the guide (9 min)