Illustrative check; not an actual record or legal approval
Track intakes and evaluate matches separately.
Intake management, client-match checking and conversion are separate operations. Checks search accessible client records, not assumed all cases, opposing parties or intakes. No match is not legal clearance.
An intake reaches the client card in six steps.
An authorized user records applicant name, email/phone, subject and source label. Selecting Web form does not collect public submissions automatically. An intake starts as New intake; lawyer assignment is optional and made during a status update.
Conversion creates a client card when eligible; it does not automatically create a case, mandate, fee agreement or privacy consent. The intake guide provides general process information; legal and operational review remain separate.
- 1/6
Intake
NewAn authorized user records subject/contact data; this is not automatic public-form ingestion. This illustration creates no record.
- 2/6
Stage and assignment
First meetingNew intake → First meeting → Agreement → Active client; intermediate stages may move to Rejected. Assigned is not a separate status; an assignee must be an active company member.
- 3/6
Client check
SearchingA name and/or valid identifier is checked against accessible client records. Name matching is limited to at most 500 selected candidates, not an exhaustive-record guarantee.
- 4/6
Match result
Illustrative matchIdentifier match, possible name match or no match is stored; these are not legal decisions. This illustrative result runs no actual check.
- 5/6
Conditional conversion
Format checkAn unconverted Active client intake is converted through a type/identifier/address form with a writable branch and required grants. A stored conflict check is not a technical prerequisite.
- 6/6
Client record
Client cardName/email/phone come from the intake; type/identifier/address from conversion. Creating a case needs separate permission and its own form; this illustration creates none.
Illustrative flow; runs no real check, conversion or case creation
New intakeNew
- Applicant
- Applicant B
- [email protected]
- Source
- Web form label; manual record
- Subject
- Rent receivable
- Assigned lawyer
- Lawyer Example
Intake
A check leaves a record.
Check client records by name and/or Turkish identity/tax number. Exact identifiers and similar names are evaluated separately; this does not search every opposing party, case party or intake. No match applies only to the query, access scope and candidate bound.
Example Logistics Inc.
1 matchIllustrative name similarity: a client record, not evidence of an opposing party in a case.
Applicant B
No matchIllustrative result; does not prove no record exists beyond access and candidate limits.
Illustrative check information
A successful check stores searched name/identifier, result details, checker user ID and time; history is paged. Optional client/case references are selected when creating the check; no later history-link editing or legal decision/note field is promised. Web/mobile history displays differ.
Results do not replace a lawyer’s legal review. Identifier matches, possible name matches and no matches are technical outcomes. History needs its own read grant and company/branch/applicable-case scope; identical lists for every lawyer or no need to check again are not guaranteed. The check guide provides general process information.
Conversion requires an unconverted Active client intake and writable branch. A type, identity/tax-number and address form is used; format/checksum validation is not official identity verification. A stored check is not a technical prerequisite; a lawyer reviews legal suitability separately. Subsequent case creation is a separate authorized operation.
What do people ask about conflict checks?
- 01/07
Which records does the search cover?
Exact identifiers and similar names are checked on accessible client records, with at most 500 selected name candidates. All cases, opposing parties or intakes are not searched. Optional client/case links are references for the check.
- 02/07
Are the results kept?
A successful check stores query/result details, user ID and time. Paged history depends on read/access scope. References are selected at creation; later linking or a legal decision/note editor is not promised.
- 03/07
Does an intake arrive automatically from the web form?
No. Selecting Web form is only a source label. This workflow does not automatically collect public-site intakes; an authorized user records the details on the intake screen.
- 04/07
Is the ID verified when converting?
The type-specific identity/tax-number format and checksum are checked. This is not an official population/tax-service lookup or verification of the person’s identity; an invalid number blocks conversion.
- 05/07
What happens if the search finds a match?
Identifier and similar-name matches are separate technical results; similar names are possible matches. A lawyer reviews the client record and decides legal conflict. Results guarantee neither legal suitability nor absence of out-of-scope records.
- 06/07
Do two lawyers research the same applicant separately?
History shows permitted accessible records. Different branch/assigned-case scopes may yield different lists; an earlier check does not necessarily replace current data and a fresh investigation.
- 07/07
Who can see an intake?
Intake reading/creation/update, conversion and conflict checks require separate grants, combined with role/direct and company/branch scope. Optional mobile case selection accepts full/assigned case reading; client selection needs its own read grant.
Start every new job with the same check.
Create intakes/checks with permission and evaluate technical matches separately from legal review.