|
| 1 | +Enable Content Flagging |
| 2 | +======================== |
| 3 | + |
| 4 | +.. include:: ../../../_static/badges/entry-adv.rst |
| 5 | + :start-after: :nosearch: |
| 6 | + |
| 7 | +Content flagging helps prevent accidental data spillage and helps system administrators respond quickly to potential leaks without disrupting collaboration. Enabling this feature empowers Mattermost users to report messages that may contain sensitive, regulated, or inappropriate information, and enables designated content reviewers to assess and take appropriate action by removing or dismissing flagged messages. |
| 8 | + |
| 9 | +By making every team member a first line of defense against sensitive-data exposure, content flagging strengthens mission-critical, secure deployments and supports compliance with organizational and regulatory data-handling standards. |
| 10 | + |
| 11 | +Before you begin |
| 12 | +---------------- |
| 13 | + |
| 14 | +You must be a System Admin in Mattermost. You need to identify who will be content reviewers for flagged messages, and you need to decide whether flagged messages should be hidden from users in Mattermost while under review. |
| 15 | + |
| 16 | +Enable |
| 17 | +------- |
| 18 | + |
| 19 | +Content flagging isn't enabled by default. To enable content flagging: |
| 20 | + |
| 21 | +1. Go to **System Console > Site Configuration > Content Flagging**. |
| 22 | +2. Set **Enable content flagging** to **True**. |
| 23 | + |
| 24 | +Alternatively, you can configure content flagging via the :ref:`config.json file or through environment variables <administration-guide/configure/site-configuration-settings:content flagging>`. |
| 25 | + |
| 26 | +Configure |
| 27 | +--------- |
| 28 | + |
| 29 | +1. Under **Content Reviewers**, define who should review flagged content: |
| 30 | + |
| 31 | + - **Same reviewers for all teams**: Set to **True** to apply one global reviewer list across all teams, or **False** to configure reviewers per team. |
| 32 | + - **Reviewers**: Start typing to search for users to assign as content reviewers. |
| 33 | + |
| 34 | + .. important:: |
| 35 | + |
| 36 | + Choose reviewers carefully. Assigning reviewer roles grants access to potentially sensitive information and may expose data from private channels. |
| 37 | + |
| 38 | + - A global reviewer can view flagged messages from all teams and channels, including private channels they’re not a member of. |
| 39 | + - Team-specific reviewers can view flagged messages from their assigned teams, including private channels within those teams they're not members of. |
| 40 | + |
| 41 | + - **Additional reviewers**: Optionally include: |
| 42 | + |
| 43 | + - **System Administrators**: System admins receive flagged messages for all teams they are part of. |
| 44 | + - **Team Administrators**: Team admins receive flagged messages for their respective teams. |
| 45 | + |
| 46 | +2. Under **Notification Settings**, specify who receives updates at each stage of the flagging workflow when content is flagged or reviewed: |
| 47 | + |
| 48 | + - **Notify when content is flagged**: Reviewer(s), Author. |
| 49 | + - **Notify when a reviewer is assigned**: Reviewer(s). |
| 50 | + - **Notify when content is removed**: Reviewer(s), Author, Reporter. |
| 51 | + - **Notify on dismissal**: Reviewer(s), Author, Reporter. |
| 52 | + |
| 53 | + All notifications are sent via the **content-review** bot as direct messages. |
| 54 | + |
| 55 | +3. Under **Additional Settings**, configure how the flagging workflow behaves: |
| 56 | + |
| 57 | + - **Reasons for flagging**: Define the preset categories that appear in the flagging dialog for users (for example: **Inappropriate content**, **Sensitive data**, **Security concern**, **Harassment or abuse**, **Spam or phishing**). |
| 58 | + - **Require reporters to add comment**: Set to **True** to require users to add a short explanation when flagging a message. |
| 59 | + - **Require reviewers to add comment**: Set to **True** to require reviewers to add a comment when resolving a flag. |
| 60 | + - **Hide message from channel while it is being reviewed**: Set to **True** to automatically hide flagged messages from the channel until reviews are complete. If a root post is flagged, the entire thread is hidden. |
| 61 | + |
| 62 | +.. tip:: |
| 63 | + We recommend enabling **Hide message from channel while it is being reviewed** and require comments from both reporters and reviewers to maintain transparency, accountability, and an auditable record of actions. |
| 64 | + |
| 65 | +Monitor flagged messages |
| 66 | +------------------------ |
| 67 | + |
| 68 | +When :doc:`a user flags a message </end-user-guide/collaborate/flag-messages>`, the **content-review** bot sends a direct message to all content reviewers. |
| 69 | + |
| 70 | +Direct messages from the **content-review** bot is a centralized moderation queue, where reviewers can view, assign, and act on flagged messages without leaving Mattermost. Reviewers can use it to monitor potential data spills, coordinate response, and maintain an auditable record of review activity. |
| 71 | + |
| 72 | +Each flagged message appears as a card-formatted message that includes: |
| 73 | + |
| 74 | +- **Flagged by**: The user who reported the message. |
| 75 | +- **Status**: The current state of the review. All flagged content starts in **Pending** status. |
| 76 | +- **Reason**: The reason selected by the reporter (for example, **Sensitive data**, **Inappropriate content**). |
| 77 | +- **Message preview**: A snippet of the flagged message, including the author, timestamp, and original channel. |
| 78 | +- **Reviewer**: The user currently assigned to review the message (initially **Unassigned**). |
| 79 | +- **Channel**: The name of the channel where the message was originally posted. |
| 80 | +- **Team**: The team context for the flagged message. |
| 81 | +- **Comment**: Any reporter-provided context. |
| 82 | +- **Post ID**: The system identifier for the original message for auditing purposes. |
| 83 | + |
| 84 | +Reviewers can select **View details** to take action as follows: |
| 85 | + |
| 86 | +- Assign a **Reviewer** responsible for reviewing the flagged message. |
| 87 | +- **Remove message**: Permanently delete the flagged message from its original channel for all users. The status of the flagged message changes to **Removed**. |
| 88 | +- **Keep message**: Dismiss the flag and restore the message if it was hidden. The status of the flagged message changes to **Retained**. |
| 89 | +- **Add a comment**: Record the reason for the decision when required. |
| 90 | + |
| 91 | +Once an action is taken, the **Status** field updates automatically. The **content-review** bot sends follow-up notifications to the reporter, author, and other reviewers based on how content flagging is configured. |
| 92 | + |
| 93 | +Deleted messages |
| 94 | +~~~~~~~~~~~~~~~~ |
| 95 | + |
| 96 | +When a reviewer permanently removes a flagged message, the message and all associated data are deleted from the database and can't be recovered, including: |
| 97 | + |
| 98 | +- Message content and properties: The text of the message and any associated post properties. |
| 99 | +- File metadata: Information about files attached to the message (e.g., file names, IDs, and links to storage). |
| 100 | +- File metadata from edit history: Information about files attached to earlier versions of the message. |
| 101 | +- Edit history: All previous versions of the message and their timestamps. |
| 102 | +- Uploaded files: The actual files stored in Mattermost’s file storage (local, S3, etc.). |
| 103 | +- Priority data: Any message priority or importance settings. |
| 104 | +- Acknowledgements: Records of users who acknowledged the message. |
| 105 | +- Reminders: Any reminders created for the message. |
| 106 | + |
| 107 | +Best practice recommendations |
| 108 | +----------------------------- |
| 109 | + |
| 110 | +Before rolling out content flagging organization-wide, we recommend communicating that the feature protects both users and the organization from accidental data spillage. Start with a pilot team to validate reviewer notifications and workflows, integrate the process with existing data-handling or incident-response playbooks, and require reporter and reviewer comments to ensure every decision is transparent and auditable. |
0 commit comments