> For the complete documentation index, see [llms.txt](https://help.fielddoc.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.fielddoc.org/manage-your-organization/collaboration.md). # Collaboration ## Collaborating in FieldDoc FieldDoc is designed to support conservation and restoration work that involves multiple people and organizations. You can collaborate by **sharing records**, **giving someone access to a Workspace**, **transferring a record**, or **linking records to a Program through a Pact**. The right option depends on what you are trying to accomplish: **Who should manage the record, who needs access to work on it, and who only needs to receive it for Program reporting or review?** ### Ways to collaborate FieldDoc supports several different ways to work across people, Organizations, and Programs: | Collaboration method | Best for | What happens | | -------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Share** | Giving another user access to selected records | The existing record remains where it is managed while the collaborator receives access to the shared record. | | **Workspace access** | Ongoing collaboration across a collection of records | The collaborator works within the Workspace and can access records available there according to their permissions. | | **Transfer** | Moving responsibility for a record to another Organization | Responsibility for managing the record moves to the receiving Organization. \[Confirm exact access behavior after transfer.] | | **Pact** | Linking Activities to a Program for reporting, review, or participation in a Program | Activity information is made available to the Program through the Pact, but the Program Manager is not invited to make changes directly to the Activity. | These options are not interchangeable. Choosing the right one helps maintain clear record ownership, access, and reporting relationships. ### Share records for focused collaboration Use **sharing** when another person or Organization needs to work with specific records but does not need general access to your Workspace. For example, you might share records with: * A technical service provider helping complete Activity information. * A partner organization collaborating on a restoration project. * A colleague who needs access to a specific group of Activities. Sharing gives collaborators access to the selected records while allowing the rest of your Workspace to remain separate. #### Sharing folders When several related Activities need to be shared, you can share a folder instead of sharing each record individually. This can make it easier to provide access to an existing collection of records. **Important:** Sharing a folder provides access to the records contained in the folder when it is shared. New Activities created in that folder later are automatically shared with the collaborator. Your collaborator can create new records in the folder and they will remain in the folder owner's [workspace](/manage-your-organization/workspaces.md). ### Use Workspace access for ongoing collaboration Use [**Workspace**](/manage-your-organization/workspaces.md) **access** when someone needs to participate more fully in managing a collection of records. A Workspace is a discrete working area with its own Activities, folders, Pacts, Metrics, and related records. Adding someone to a Workspace allows that person to work within the Workspace according to their permissions. Workspace collaboration can be useful for: * Technical service providers managing records on behalf of another Organization. * Long-term project partners. * Consultants who need to create, organize, or update multiple Activities. * Collaborations where several people need to work from the same record structure. #### Workspace access versus sharing The main difference is **scope**. Sharing gives someone access to selected records. Workspace access gives someone access to the Workspace and the records available within it according to their permissions. If someone only needs to review or update a few Activities, sharing may be the better choice. If they are helping manage a larger body of work over time, Workspace access may be more appropriate. ### Transfer records when responsibility changes Use a **transfer** when the Organization responsible for managing a record needs to change. Unlike sharing, a transfer is intended for situations where the receiving Organization should become responsible for the record rather than simply collaborate on it. For example, a transfer may be appropriate when: * One Organization created a record that should be managed by another Organization. * Responsibility for managing an Activity moves from one Organization to another. * A partner created initial records and is handing ongoing stewardship to the Organization responsible for the work. Before transferring a record, confirm whether the originating Organization should continue to have access and whether additional sharing is needed after the transfer. Transfers should be used carefully when records are connected to a Pact, Program, award, or reporting requirement. ### Use Pacts to report or participate in a Program A **Pact** links Activities to a Program Opportunity for a defined purpose, such as grant reporting, Program review, or participation in a collaborative Program. Pacts are different from sharing or Workspace access because the relationship is **uni-directional**. When you link an Activity to a Pact, you make that Activity available to the Program according to the Program's reporting and configuration requirements. The Pact does **not** invite the Program Manager to become a collaborator on the underlying Activity. This means a Program Manager can review and use information submitted through the Pact without automatically receiving permission to edit or manage the Activity itself. If a Program Manager or another user needs to work directly on the Activity, you must use a separate collaboration method, such as **sharing** the record or providing appropriate **Workspace access**. #### Pacts versus direct collaboration Use a Pact when the goal is to: * Report Activities to a funding or reporting Program. * Submit records for Program Manager review. * Connect Activities to Programmatic Metrics, Activity Types, Models, or other Program requirements. * Participate in a Program while continuing to manage the underlying Activities within your own Workspace. Use sharing or Workspace access when another person needs to **work directly on the record**. A Pact establishes a reporting and Program relationship. It does not, by itself, establish a collaborative editing relationship. ### Sharing is not the same as transferring responsibility This distinction is central to collaboration in FieldDoc. When you **share**, you give someone access to an existing record while the record remains managed in its current context. When you **transfer**, responsibility for managing the record moves to another Organization. When you use a **Pact**, you link the record to a Program for reporting or review without giving the Program Manager collaborative access to the underlying record. ### Choose the right collaboration method A simple way to decide is to ask what the other person or Organization needs to do: **Do they need access to specific records?**\ Use **sharing**. **Do they need ongoing access to work across many records?**\ Use **Workspace access**. **Should another Organization become responsible for managing the record?**\ Use **transfer**. **Do the records need to be reported to or reviewed within a Program?**\ Use a **Pact**. If a Program Manager also needs to work directly on the record, use a separate sharing or Workspace collaboration method in addition to the Pact. ### Manage collaboration carefully Periodically review collaboration when: * A consultant or technical service provider finishes their work. * A partner's role changes. * Responsibility for an Activity changes. * A user no longer needs access to a Workspace. * A Program relationship ends. * A record appears in the wrong Organization or Workspace. Keeping collaboration methods distinct helps users understand who manages a record, who can work on it, and where its information is being reported. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.fielddoc.org/manage-your-organization/collaboration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.