{
  "title": "Team Ownership & Collaboration",
  "internal_name": null,
  "slug": "team-ownership",
  "url": "https://alefos.ai/documentation/team-ownership",
  "json_url": "https://alefos.ai/documentation/team-ownership.json",
  "summary": "Keep one clear owner while the right teammates contribute without taking over the customer relationship.",
  "description": "AlefOS Team makes responsibility visible across contacts, missions and appointments with a company queue, one primary owner and section-level collaborators.",
  "category": "Business",
  "last_updated": "2026-07-23",
  "keywords": [
    "Team ownership",
    "company queue",
    "primary owner",
    "collaborators",
    "assignments",
    "permissions"
  ],
  "sections": [
    {
      "heading": "Why ownership exists",
      "content": "Shared company memory still needs clear responsibility.\n\nAlefOS Team separates the person responsible for the customer from the teammates who are allowed to help. Everyone can see who owns the next step without closing useful context inside one person account."
    },
    {
      "heading": "Company queue",
      "content": "New, released or unassigned work can remain in the company queue.\n\nThe company queue means the customer, mission or appointment is visible to the authorized company scope but does not yet have one responsible member.\n\nReturning work to the queue removes the individual owner without deleting the context or making the work disappear."
    },
    {
      "heading": "Primary owner",
      "content": "A contact, mission or appointment can have one primary owner.\n\nThe primary owner is the person responsible for the relationship or next action. Assignment, reassignment and takeover are explicit. A collaborator never silently becomes the owner."
    },
    {
      "heading": "Observers and contributors",
      "content": "Selected teammates can help without taking over responsibility.\n\n- Observer: can read only the granted sections.\n- Contributor: can help only inside the granted sections.\n\nThe role is visible and separate from primary ownership."
    },
    {
      "heading": "Section-level permissions",
      "content": "Collaboration can be limited to exact parts of the customer memory.\n\nFor example, a teammate may be allowed to contribute to notes while customer identity, private conversations or other protected sections remain unavailable.\n\nPermissions follow the authorized tenant scope and never grant silent access to the entire company memory."
    },
    {
      "heading": "Expiry, revocation and audit",
      "content": "Collaboration access can include an expiry date and can be revoked.\n\nAssignments, role changes, access changes and revocations are audited. This keeps responsibility and access understandable after work changes hands."
    },
    {
      "heading": "Contacts, missions and calendar",
      "content": "The same ownership model follows the work across the main Team objects.\n\n- Contacts keep one relationship owner and optional collaborators.\n- Missions keep one responsible assignee or return to the company queue.\n- Calendar appointments keep one visible owner while preserving customer context and linked missions.\n\nResponsibility remains visible from the customer relationship to the next action."
    },
    {
      "heading": "MCP tools",
      "content": "Authorized AI assistants can use protected ownership tools to prepare changes:\n\n- contacts.assign\n- contacts.collaborators_list\n- contacts.collaborator_set\n- contacts.collaborator_remove\n- missions.assign\n- calendar.assign\n\nPermission checks, user validation when required and audit trails still apply."
    },
    {
      "heading": "Key takeaway",
      "content": "Team ownership answers three questions immediately: who is responsible, who can help and what each person is allowed to access.\n\nOne primary owner. The right collaborators. No silent takeover."
    }
  ],
  "typical_questions": [
    "Who owns this customer?",
    "Which customer files are still in the company queue?",
    "Who can contribute to this customer's notes?",
    "Assign this mission to Sarah.",
    "Return this appointment to the company queue.",
    "Give David contribution access to notes only."
  ],
  "related_pages": [
    "team",
    "contacts",
    "missions",
    "calendar",
    "mcp-cockpit",
    "deployment"
  ],
  "important_notes": [
    "Team collaboration never means impersonation.",
    "Assignment and collaboration changes are permission-checked and audited."
  ],
  "markdown": "# Team Ownership & Collaboration\n\nLast updated: 2026-07-23\n\nAlefOS Team makes responsibility visible across contacts, missions and appointments with a company queue, one primary owner and section-level collaborators.\n\n## Why ownership exists\n\nShared company memory still needs clear responsibility.\n\nAlefOS Team separates the person responsible for the customer from the teammates who are allowed to help. Everyone can see who owns the next step without closing useful context inside one person account.\n\n## Company queue\n\nNew, released or unassigned work can remain in the company queue.\n\nThe company queue means the customer, mission or appointment is visible to the authorized company scope but does not yet have one responsible member.\n\nReturning work to the queue removes the individual owner without deleting the context or making the work disappear.\n\n## Primary owner\n\nA contact, mission or appointment can have one primary owner.\n\nThe primary owner is the person responsible for the relationship or next action. Assignment, reassignment and takeover are explicit. A collaborator never silently becomes the owner.\n\n## Observers and contributors\n\nSelected teammates can help without taking over responsibility.\n\n- Observer: can read only the granted sections.\n- Contributor: can help only inside the granted sections.\n\nThe role is visible and separate from primary ownership.\n\n## Section-level permissions\n\nCollaboration can be limited to exact parts of the customer memory.\n\nFor example, a teammate may be allowed to contribute to notes while customer identity, private conversations or other protected sections remain unavailable.\n\nPermissions follow the authorized tenant scope and never grant silent access to the entire company memory.\n\n## Expiry, revocation and audit\n\nCollaboration access can include an expiry date and can be revoked.\n\nAssignments, role changes, access changes and revocations are audited. This keeps responsibility and access understandable after work changes hands.\n\n## Contacts, missions and calendar\n\nThe same ownership model follows the work across the main Team objects.\n\n- Contacts keep one relationship owner and optional collaborators.\n- Missions keep one responsible assignee or return to the company queue.\n- Calendar appointments keep one visible owner while preserving customer context and linked missions.\n\nResponsibility remains visible from the customer relationship to the next action.\n\n## MCP tools\n\nAuthorized AI assistants can use protected ownership tools to prepare changes:\n\n- contacts.assign\n- contacts.collaborators_list\n- contacts.collaborator_set\n- contacts.collaborator_remove\n- missions.assign\n- calendar.assign\n\nPermission checks, user validation when required and audit trails still apply.\n\n## Key takeaway\n\nTeam ownership answers three questions immediately: who is responsible, who can help and what each person is allowed to access.\n\nOne primary owner. The right collaborators. No silent takeover.\n\n## Typical questions\n\n- Who owns this customer?\n- Which customer files are still in the company queue?\n- Who can contribute to this customer's notes?\n- Assign this mission to Sarah.\n- Return this appointment to the company queue.\n- Give David contribution access to notes only.\n\n## Important notes\n\n- Team collaboration never means impersonation.\n- Assignment and collaboration changes are permission-checked and audited."
}