Owner, assigned, and marked

Every record in JAI CRM has one owner. Beyond that, people get attached to it for two different reasons: because they are doing some of the work, or because they need to watch it. Those are not the same thing and the product does not treat them as the same thing. Mixing them up is how a colleague who was copied in for information ends up deleting a lead.

app.jaicrm.ai

There are three attachments, and this page is about the difference between them.

The three, side by side

Two gates decide every action, and both have to open. The first is the role: does this person hold Edit on Leads at all. The second is the record: what does this particular lead give them. The table above is the second gate only. Somebody whose role has no Delete on leads cannot delete a lead they own, because the first gate is checked before the second.

The owner

One person, and the anchor for every decision about who else sees the record. When you create anything the owner is you, unless you name somebody else on the form.

Creating a lead, a CRM task or a project with an owner sends that module’s assigned notice, and so does handing one over afterwards. Save a record whose owner has not changed and no assigned notice goes out — though a stage or status move on the same save still raises its own, which is how a deal set to Won sends Deal won without the owner moving. No other module has an assigned notice to send: deals, companies, visits, vendors, documents, subscriptions and expenses have no assigned template at all, so changing the owner there sends nothing either way.

The owner is what a narrowed data scope reads. A role set to Their own records or Their team’s records under Settings → Roles & permissions matches on the owner column. Where a record has no Owner field at all — an expense, a warranty, a quality inspection — whoever created it stands in as the owner for this purpose.

The owner is also what the organisation tree reads. Somebody above the owner in Settings → Roles & permissions → Organisation tree reaches the record because of who owns it. Hand a lead to somebody on another desk and it moves into that desk’s manager’s reach — but not out of everybody else’s. Whoever raised it keeps it, and it still lists for their own manager, who is then refused when they try to open it. Assigning somebody, or marking them, moves nothing.

The assignee

The extra people named on a record because they are doing some of the work. A record can carry any number. On the CRM lists they show in the Marked to column beside the owner — called Also going on visits, and not on the companies list at all. On a project’s People tab they are listed as Assigned, and that tab is where you add one. On a project task, Assigned to is a single field and is the person the task sits with. A CRM record has no assignee box on its form, so on a lead or a deal an extra assignee can only be set over the API.

An assignee is read as somebody working on the record, so on that record they get the same reach the owner has: open it, change it, delete it. Their role still caps what that means — an assignee whose role holds only View and Edit on Deals can open and edit the deal and cannot delete it.

Assigning does not change ownership. A lead owned by Priya and assigned to Anjali is still Priya’s lead for every scope question, and still sits under Priya’s manager on the tree, not Anjali’s.

Mark to

Mark to is the field for everybody else: the people who need to see the record and follow what happens to it, and who are not doing the work. It takes as many names as you like. The field’s own help text on the form says what it means — kept in the loop, they can see it, they do not own it.

What being marked grants is reading. Not editing. Not deleting. Not approving, converting or exporting. Reading is the whole of it, and that is deliberate: being copied in on a lead should not hand somebody the right to erase it.

Marking somebody

1. Open the record — a lead, a deal, a customer, a task, a vendor, a project, a quotation.
2. Find Mark to on the form. It is a box that takes several people.
3. Add the names and save. Each one is now a watcher row on the record; on a project’s People tab they are listed as Watching.
4. To take somebody off, remove their name from the box and save again.
5. On a project task the field sits in the task panel instead, where it only adds — there is no control for taking a name off again — and the task views carry a Marked to me tick box that filters to it.

A floor, never a ceiling

Being marked can only add reading to somebody who had nothing. It never subtracts from somebody who already had more. A manager marked on a subordinate’s lead keeps everything the organisation tree already gave them, because marking your manager should not quietly demote them on that one record.

This is the part that causes the arguments. The mark is not a permission level you are setting on a person. It is a minimum. Whatever else reaches that person — their role’s data scope, their place on the tree, a sharing rule, the organisation’s default for the module — is weighed afterwards, and the widest of all of it wins.

The worked example

Priya Nair, a sales executive in Coimbatore, is working a lead: Sundaram Textiles, 250 uniform sets at ₹1,920 each, expected value ₹4,80,000, and a quotation raised at ₹4,80,000 plus 12% GST of ₹57,600 — ₹5,37,600 in all. She owns the lead. Her role is set to Their own records on Leads, with View, Create, Edit, Import and Convert, and no Delete or Export.

She marks it to three people: Rakesh Menon, her manager; Anjali Deshpande, who runs the Chennai desk on a copy of the Manager role that Priya’s role does not report to; and Suresh Iyer, the accountant.

Anjali is the case worth reading twice. She is senior, she has run a desk for years, and her role holds Delete on leads. The mark still gives her reading only, because seniority is not something the product reads. The organisation tree is. Rakesh can act on the lead not because he is the manager but because Priya’s role sits under his on the chart.

If Anjali genuinely needs to act on it

• Assign her, rather than marking her — an assignee gets edit and delete on that record. On a project you add one from the People tab, and on a project task you set Assigned to. A CRM record has no assignee box on its form, so on a lead this can only be done over the API, and the sharing rule below is the practical answer.
• Write a sharing rule under Settings → Roles & permissions → Data sharing settings: shared from Sales executive, shared with her role, permission Read/Write. This covers every lead that role owns, not one.
• Move the roles on the tree, if Priya’s desk really does report to Anjali. This is the heaviest change and reaches every module at once.

What a superior may do, and where that is set

Everybody above the owner on the organisation tree reads their records either way. What else they may do is one setting, at the top of Settings → Roles & permissions → Organisation tree, called “What a superior may do to a subordinate’s records”.

It is one answer for the whole business, across every module. It does not touch assignees, who get the full right either way, and it does not touch marked people, who get reading either way. The exception worth knowing is the widest data scope: a role set to Everything in the business on a module is answered before the setting is read at all, so those people keep delete on every record they can reach even where the business has chosen “Edit them, but not delete”.

Which modules carry Mark to

Mark to is offered on the record types somebody would reasonably want to follow:

• CRM — leads, companies, customers, deals, tasks and visits
• Vendors — the vendor record
• Projects — projects and project tasks
• Sales and purchase documents — one field set covers quotations, sales orders, proformas, invoices, bills of supply, retainer invoices, credit notes, delivery challans, purchase orders, purchase bills and debit notes
• Subscriptions — the customer’s subscription
• Warranty — the warranty register
• Manufacturing — a manufacturing order can be marked over the API, but its screens are hand-built and draw no Mark to box, so there is nothing to fill in
• Quality — the same for an inspection: the API saves a mark, and the inspections list and the inspection record have no box on them
• Finance — an expense draws a Mark to box and the expense routes never read it. The names are dropped on save, the toast says Saved and nobody is marked. Use a sharing rule there until it is wired up.

It is deliberately absent from the records nobody watches: items, price lists, bills of materials, packages, assemblies, subscription products, plans, addons and coupons, quality templates and rules, and employees. A coupon has no story to follow.

How each one appears in a notification

A notification template says who it goes to rather than naming people, so it survives somebody leaving. Under Notifications → Templates, the “Goes to” box offers five tick boxes, and three of them are the three attachments on this page.

Two modules read “Owner” as the person the work is waiting on rather than a field called Owner. On a quality inspection it means the inspector named on it, falling back to whoever raised it. On a project task it means the person it is assigned to, falling back to the project’s owner.

Marked is already ticked on 43 of the 97 shipped templates. Some are escalations — Lead going cold at 21 days of silence, Task overdue — escalation at a week, Deal won, Deal lost and Quotation accepted. Many are routine notices: Goods received, Project completed, Transfer arrived, Run finished, A colleague has joined and the weekly digests all carry it. The escalations are the shape worth copying on a template of your own: the owner hears about it early and on their own, and the people watching are brought in when it stops going to plan.

Everyone can still turn a module’s messages off, or down to a digest, under Settings → My notifications. Being marked does not override somebody’s own preference.

What marking will not do

• It does not change who owns the record. The record does turn up in the marked person’s own lists — that is what makes a mark useful to somebody on Their own records — but it is not theirs: the Owner column names somebody else, and a report that counts records by owner counts it against them, not against the person watching.
• It does not widen their role. A module their role cannot open stays shut, and nothing on the record says why — the module permission is checked first, so a marked lead simply is not there.
• It does not narrow anybody. Marking a manager who already had edit and delete leaves them with edit and delete.
• It does not add an action to their role. It gives reading — not approving, converting, printing or exporting. Where their role already holds Export on that module, the marked record will be in the file, because it is in the list.
• It is not retrospective for the messages that already went out. An event notice that fired before somebody was marked is not re-sent to them; a date-based chase will reach them on the next sweep while the condition still holds.
• Taking somebody off Mark to does not unsend anything, and the form leaves no trail either: a save that changes only the marks records that the record was updated, and names nobody. The record’s own assignee endpoints do write named history, but no screen in the app calls them — so keep your own note if you will need one.

The ones that catch people out