Who can open a saved email or document list?
Members can read the material their existing source access allows. To give another audience selected information, create a separate shared view with its own access settings.
Give colleagues access to the information they need for their work. Share selected details with customers, advisers or connected applications, with separate controls for sensitive values and original files.
Internal review
Colleagues can open the supporting email when their access allows.
Customer view
The customer sees the chosen details without access to original files.
Choose what each organization role can do and which connected sources a member can read. Their searches, saved lists and reviewed data respect that source access.
Create focused email or document lists for recurring work while keeping those access settings in place. Each colleague can open the material they have permission to read.
Create a separate shared view for the chosen audience. Include the emails, documents or fields they need, then choose supporting links, related files and downloads separately.
Give an internal buyer the delivery email and price, while a customer sees the date. Turn off original-file access when an attachment contains private information: hiding a field in the view leaves the original file unchanged.
Remove, mask or replace supported values before sharing them. Use hashes, aliases or tokens when a recipient needs consistent identifiers, and generalize dates or numbers where appropriate. Apply text detectors to chosen fields and supported sanitized HTML.
Remove filenames or related metadata from the shared description when needed. These controls shape shared fields, text and metadata; original PDFs and other attachments remain intact and have separate download controls.
Preview the export or API response with the sharing policies applied. Create separate views when customers and internal teams need different details.
Set a password or expiry date, restrict permitted email addresses where supported and require code verification when appropriate. Choose whether the reader can open details, supporting links or original files.
Review the link as the intended recipient to see the information and downloads available to them. Keep those choices with the view’s audience settings.
Give an application credentials for a chosen read-only view. For AI context, authorize one view or a catalog of eligible views through MCP or REST, with the same field and file controls applied to each read.
Choose permitted downloads, retrieval limits and purpose requirements. Revoke credentials when access is no longer needed; replacing a token leaves the old one active until revoked. See the AI connection guide for supported clients.
See what a colleague, outside recipient or application can search, open and download using their own access. Review recorded requests and applied sharing policies when you need to investigate.
Use sign-in controls for member identity and access history to follow recorded activity.
Members can read the material their existing source access allows. To give another audience selected information, create a separate shared view with its own access settings.
Redaction changes supported shared fields, text or metadata while the original attachment stays intact. Turn original-file access off when the recipient should receive only the selected information.
Yes. A snapshot keeps its completed content, with the relevant access and sharing policies still applied when someone reads it.
Compare a colleague’s view with a customer’s view, including the visible fields, supporting links and downloadable files.