These terms are between Centre for Advanced Practical Project Management (“CAPPM”, “we”) and each organization that uses the platform (the “Customer”). The Customer's users, its staff and its consumers, are covered by the Customer's own terms and privacy notice. How we process their personal data for the Customer is set out in the Data Processing Agreement, which forms part of these terms.
1. Roles
The Customer is the Data Fiduciary for the personal data of all its users, staff and consumers alike, including the sign-in identities they use within its organization and apps. CAPPM is the Customer's Data Processor for that data and acts only on the Customer's instructions, including the Standard Instructions in the Data Processing Agreement, section 3.
CAPPM is the Data Fiduciary only for the Customer's business contacts: its owners, its administrators as contacts, and its billing contacts (Customer Privacy Notice).
2. The Customer's users
- Staff on a verified domain (section 5) may use the Customer's staff apps once they are members of its organization; people may join by their email domain only if the Customer turns that on.
- Staff outside a verified domain (for example a contractor at
user@agency.comoruser@gmail.com) may use the Customer's staff apps only by the Customer's explicit invitation. By inviting them, the Customer takes on the role of Data Fiduciary for their identity within its organization. Without an invitation, such an account cannot join or use the Customer's staff apps. - Consumers of the Customer's public apps sign up with a verified email address, and use only those apps.
A person who uses several Customers has one sign-in. Each Customer is responsible for that identity within its own organization and apps, and no Customer's instruction affects another's. We keep an identity only while at least one Customer uses it, and erase it when none does.
The Customer gives its users its own privacy notice, naming itself as their Data Fiduciary, and sets its address in its settings; it must do so before it opens sign-up to the public.
The Customer's owner accepts the Data Processing Agreement for the Customer, in its organization's settings. Until they do, no one new can join the Customer's organization or sign up on its public apps: invitations, public sign-up and joining by email domain wait for the acceptance, while the members and apps already there keep working. When we publish a new version of the agreement, we email the owner, who accepts it again; their acceptance of the previous version keeps letting people join for 30 days after the new version takes effect, and we remind them a week before that ends.
3. Removing users, and account deletion
The Customer may remove a user from its organization or apps at any time; their access within its scope ends at once. The Customer deals with its own records about them. If the person then uses no other Customer, we erase their identity 14 days later, after telling them, as the Customer instructs in the Data Processing Agreement.
On the Customer's Standard Instruction, we also offer its users a self-service tool to delete their account, and let them leave its organization where it allows members to leave. The Customer is told on the day a user asks.
4. Deleting an organization
The owner of an organization can delete it. The deletion takes effect 30 days after it is requested. Every member is told on the day it is requested, and the owner can cancel until it takes effect. During those 30 days the organization's administrators can download its data.
When the deletion takes effect, all of the organization's data is deleted and cannot be recovered, including its apps, its users' access, its settings, and all employee records, payslips, documents and other files held in HRMS. A user's identity is erased too, unless another Customer still uses it (section 2).
Statutory records must be exported first. We keep no copy of a deleted organization's data. Before a deletion can be scheduled, the person scheduling it must confirm, by ticking a box, that “all statutory records of this organization (payroll, TDS, PF, ESI and wage registers) have been exported before scheduling its deletion”. We record that confirmation, with who gave it and when, and keep the record after the organization is deleted. The Customer remains responsible for keeping the records the law requires it to keep.
5. Verifying a domain
The Customer verifies a domain by publishing a DNS TXT record on the domain, or a file at https://<domain>/.well-known/collab-verification.txt, holding a value we provide. No other method is accepted: an email address on the domain, including administrative ones such as admin@ or postmaster@, does not verify it. By verifying a domain, the Customer confirms that it controls it. Only one Customer can verify a given domain, and we may withdraw a verification obtained without that control.
We check the record or file weekly. If it is missing, we check daily and tell the Customer's owners and administrators on days 1, 7 and 12. If it is still missing on day 14, the domain lapses, and the accounts that relied on it (people who joined by the domain, or are on it and were not explicitly invited) are suspended: they cannot use the Customer's apps. Nothing is deleted. The suspension ends when the Customer verifies the domain again, moves those people to another verified domain, invites them explicitly, or removes them (section 3).
6. Suspension
A suspension applies within one Customer's organization only: a person suspended there can still use any other Customer they belong to. We suspend accounts as set out in section 5, and otherwise only on the Customer's instruction or as these terms allow.