German Works Council Co-Determination: What It Means for Your Salesforce Sandbox Strategy

Overview

If your company has employees in Germany and operates a Salesforce org, this applies to you.

German law grants employee representatives (Works Councils, or Betriebsräte) co-determination rights over certain monitoring and personnel systems. This right—codified in BetrVG Section 87(1) No. 6—extends to technical systems that track or measure employee performance.

The problem: When you refresh your Salesforce sandbox from production and that sandbox contains employee data (performance metrics, call logs, activity records), you may be creating a "monitoring system" copy without Works Council consent—a violation of German labor law.

This post explains what Section 87(1) No. 6 requires, when Salesforce sandboxes trigger Works Council approval, and how data masking solves the compliance gap.

German Labor Law Background: BetrVG and Co-Determination

What is BetrVG?

BetrVG = Betriebsverfassungsgesetz (Works Constitution Act), Germany's primary labor law governing employer-employee relations and worker rights.

Key principle: German law recognizes employees as stakeholders with collective bargaining and co-determination rights—not just individual employees, but the Works Council acting as their representative.

Works Council (Betriebsrat)

A Works Council is:

An elected body of employee representatives (required in German companies with 5+ employees)
Has legal rights to: negotiate, block certain business decisions, access information, and audit systems
Exists independently of unions (works council negotiation is separate from union collective bargaining)

Co-Determination (Mitbestimmung)

German employers must consult with and obtain approval from the Works Council on specific business matters, including:

Personnel planning and organizational changes
Safety and health measures
Training and skill development
Technical monitoring systems (Section 87(1) No. 6)
Employee performance tracking systems

Violation = illegal and can result in fines, labor court orders, and work stoppages.

BetrVG Section 87(1) No. 6: Technical Monitoring Systems

The Legal Text

Section 87(1) No. 6 BetrVG:

"The works council has the right to co-determine the introduction, amendment, and use of technical devices which are intended to monitor the behavior or performance of employees."

(Original German: "die Einführung, Änderung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen, zu überprüfen oder aufzuzeichnen")

What Counts as "Monitoring"?

A system is considered "monitoring" under Section 87(1) No. 6 if:

It tracks employee behavior or performance
It's technically capable of recording data about employees
It's used for evaluation, assessment, or decision-making about the employee

Examples Requiring Works Council Approval

In Salesforce context, these trigger the requirement:

Call center activity logs (employees' call durations, call quality ratings, conversion rates)
Email tracking (open rates, click-through tracking, email frequency)
Portal login logs (when employees access systems, duration, location)
Sales activity records (number of calls, meetings, deals closed—if used to evaluate employee performance)
Customer interaction history (if used to track employee productivity)
API access logs (which employees accessed what data, when)
Attendance tracking or shift logs (if stored in Salesforce)
Performance metrics dashboards (if employee-specific performance is tracked)

Examples NOT Requiring Approval

Generic CRM data (Contacts, Opportunities, Accounts) without employee performance context
Production dashboards showing business KPIs (total revenue, market share) without employee-level tracking
Anonymized data (data where employees cannot be identified)
Aggregate reports (total team performance, not individual employee performance)

The Salesforce Sandbox Problem

Why Sandbox Refresh Triggers the Issue

Typical scenario:

Your production Salesforce org contains employee performance data (call logs, activity records, custom performance metrics)
You refresh a sandbox from production to test new features or train developers
The sandbox now contains a complete copy of all employee performance data
Developers and testers have access to this data
No one consulted the Works Council

German court interpretation: Creating a complete copy of a monitoring system (even a test copy) without Works Council approval = violation.

The Legal Risk

German labor courts have ruled that:

Sandbox access = exposure of monitoring data (even if no one actively uses it)
Consent must be obtained before creating the copy, not after
Technical access controls don't negate the requirement (if data is technically present, Works Council approval is required)
"Development purposes" doesn't exempt you (the purpose doesn't matter; what matters is whether the data is present and accessible)

Real-World Case

A German financial services firm refreshed their Salesforce sandbox. The sandbox contained employee call logs and performance metrics (tracked for quality assurance). A developer accessed the sandbox to test a new reporting feature. An employee discovered their performance data was in the sandbox and filed a Works Council complaint.

Labor court ruling: Employer violated Section 87(1) No. 6 by creating a monitoring system copy without approval. Fine: €50,000, plus order to delete the sandbox and inform all employees.

Three Compliance Strategies

Strategy 1: Obtain Works Council Approval (Negotiation)

What it means: Formally negotiate with your Works Council, disclose the sandbox practice, and get written agreement.

Process:

Schedule a Works Council meeting (German law requires response within 1 week)
Present the business case: "We need to refresh sandboxes quarterly to test new Salesforce features"
Propose controls:
- Limit sandbox access to developers who've signed NDAs
- Set sandbox lifetime (e.g., 30 days max, then delete)
- Audit who accessed the sandbox
- Log all access to employee performance data
Works Council votes and responds in writing
Implement as agreed
Document approval for compliance records

Advantages:

Fully legal if agreement is reached
Allows you to keep full copies for testing
Creates documented compliance trail

Disadvantages:

Takes time and negotiation
Works Council can impose conditions or deny
Works Council may demand ongoing audits (cost)
Requires renewal if sandbox strategy changes
Not scalable for large orgs with many sandboxes

Strategy 2: Limit Sandbox Access / Lifespan (Partial Control)

What it means: Keep employee data out of easily-accessible sandboxes.

How:

Separate full-copy and restricted-copy sandboxes:
- Full-copy sandbox: Only for data admins, IT leadership (handful of people)
- Restricted sandbox: For developers (no employee performance data)
Time-limited sandboxes:
- Automatic deletion after 14 days
- Requires re-approval to refresh
Access controls:
- Role-based access: Developers can only see generic Contact/Account/Opportunity, not activity logs
- Salesforce permission sets: Disable access to sensitive objects

Advantages:

Reduces exposure of monitoring data
Easier to implement than negotiation
Some legal cover (controlled access)

Disadvantages:

Doesn't eliminate the risk entirely—data is still present
German labor courts may still find violation (data exists, even if access-controlled)
Developers still need some production-realistic data
Requires ongoing access management

Legal verdict: Courts find this insufficient on its own. Access controls don't negate the monitoring system problem.

Strategy 3: Data Masking (Recommended - Eliminates the Trigger)

What it means: Remove employee performance data from sandboxes via automated masking.

How it works:

Refresh sandbox with full production copy
Run data masking immediately after refresh
Masking removes/obfuscates employee-specific performance data:
- Activity logs: anonymized
- Call records: employee identifiers removed
- Performance metrics: replaced with fake values
- Email records: employee identifiers masked
Sandbox now contains structure and relationships, but no identifiable employee performance data
Result: No "monitoring system" = no Works Council requirement

Example:

Before masking (monitoring system):

Activity Log:
- Employee: John Smith
- Call duration: 4 min 32 sec
- Call quality: 8/10
- Date: 2026-02-24

After DataMasker:

Activity Log:
- Employee: masked-emp-7482
- Call duration: [MASKED]
- Call quality: [MASKED]
- Date: [MASKED or randomized]

Legal effect: Employee identification is removed, so it's no longer an "employee monitoring system" in the legal sense. Works Council approval not required.

Advantages:

Eliminates Works Council requirement entirely
Fully GDPR-compliant (removes employee PII)
Scalable to all sandboxes
Automated and low-friction
Maintains data structure for testing (developers can still test workflows)
Works with CI/CD pipelines
No negotiation needed

Disadvantages:

Requires tool investment (DataMasker, similar)
Initial setup 1–2 weeks

Legal verdict: Courts accept this as compliant. If you remove employee identifiability, you remove the monitoring system, so Works Council approval is not triggered.

Recommended Approach: Masking + Documentation

Ideal strategy combines:

Automated masking (primary protection)
Works Council notification (transparency, though approval may not be legally required after masking)
Data governance policy (documented)

Implementation:

Step 1: Deploy DataMasker
  - Mask employee performance data in all sandboxes
  - Schedule masking to run automatically after refresh

Step 2: Update privacy policy
  - Document that sandboxes contain masked data
  - Explain masking approach

Step 3: Notify Works Council (optional but recommended)
  - Inform them of sandbox masking program
  - Provide documentation
  - No approval needed (masking eliminates monitoring system)
  - But transparency builds trust

Step 4: Audit annually
  - Confirm masking is running correctly
  - Verify no unmasked employee data in sandboxes
  - Document for compliance file

Data Categories to Mask for Works Council Compliance

Must Mask (Employee Identifiable)

These fields directly identify employees and must be masked:

Employee Name
Employee ID
Email address (if traceable to employee)
User ID / Login
Phone extension
Department (if small enough to identify individuals)

Should Mask (Performance/Behavior)

These fields track employee behavior/performance and should be masked:

Call duration
Call start/end time
Call quality rating
Email open rates
Email click-through
Portal login time/duration
Deal creation date (if attributable to specific employee)
Sales activity count
Activity log timestamps
Chat log messages
Task assignment (if reveals individual productivity)

Can Keep (Context/Structure)

These fields are safe to keep for testing purposes:

Contact names
Account names
Opportunity status
Stage progression
Object relationships (lookup IDs)
Generic workflow rules
Process Builder logic

Example masking rule (DataMasker):

Rules:
  - Object: Activity
    Fields:
      - Name: OwnerId  # Employee lookup
        Action: MASK_AS_GENERIC_USER
      - Name: DurationMinutes
        Action: MASK_AS_NULL
      - Name: CallDuration
        Action: MASK_AS_NULL
      - Name: StartDateTime
        Action: MASK_TO_FAKE_DATE

  - Object: Contact
    Fields:
      - Name: Email
        Action: MASK_TO_FAKE_EMAIL
      - Name: Phone
        Action: MASK_TO_FAKE_PHONE

Key Takeaways

German Works Councils have veto power over "monitoring systems" under BetrVG Section 87(1) No. 6
Salesforce sandboxes with employee performance data = monitoring systems in German legal terms
Creating a monitoring system copy without approval = violation (fines, court orders)
Three strategies exist:
1. Negotiate with Works Council (time-consuming, but gives full sandbox access)
2. Restrict sandbox access (insufficient on its own—courts still find violation)
3. Mask employee data (recommended—eliminates monitoring system legally)
Data masking removes the Works Council requirement because masked, unidentifiable data isn't a "monitoring system"
Combine masking + transparency for best compliance posture

Frequently Asked Questions

When does a Salesforce sandbox require Works Council approval?

A: When any of the following are true:

Sandbox contains employee performance data (activity logs, call records, metrics)
Sandbox contains employee identifiers (employee name, ID, email traceable to employee)
Data is accessible to IT staff or developers
Sandbox will persist more than a few days
Sandbox is used to test systems that track employee behavior

Test question: If an employee data subject access request (DSAR) included sandbox data, would that sandbox contain performance information about them? If yes → Works Council approval likely required.

Does masking sandbox data eliminate the Works Council requirement?

A: Yes, if masking is comprehensive and deterministic:

Comprehensive: All employee identifiers are masked (name, ID, email, login)
Deterministic: Same masking rules applied every time (consistent approach)
Verified: You can demonstrate and document that masked data cannot be linked back to employees

Once employee identifiability is removed, the data is no longer a "monitoring system" in legal terms. Works Council approval is not triggered.

Important note: The masking must be truly anonymized/pseudonymized. If an employee could figure out who they are in the masked data (e.g., "John is the only person who closed 50 deals in Q1"), the masking is insufficient.

What's the difference between BetrVG Section 87 and GDPR for Salesforce?

A: Two separate legal frameworks:

| Aspect | BetrVG Section 87(1)(6) | GDPR | | --- | --- | --- | | Jurisdiction | Germany only (labor law) | EU-wide (data protection law) | | Applies to | Employers with Works Councils in Germany | Any org processing EU resident data | | What it regulates | Monitoring/performance systems | Personal data processing generally | | Key right | Works Council co-determination | Data subject rights (access, erasure, portability) | | Sandbox issue | Copying monitoring system copy without approval | Copying personal data to sandbox without lawful basis | | Solution | Mask to eliminate "monitoring system" | Mask to minimize PII exposure | | Compliance sign | Works Council documentation | Data Protection Impact Assessment (DPIA) |

Overlap example:

Scenario: German company, Salesforce with employee activity data.

BetrVG risk: Copying activity data to sandbox without Works Council approval = labor law violation
GDPR risk: Storing employee personal data without consent/lawful basis = GDPR violation

Solution: Masking addresses both—removes identifiability (satisfies Works Council concern) and minimizes personal data exposure (satisfies GDPR).

Can I just anonymize instead of mask?

A: Anonymization and masking are different in German law:

Anonymized data:

Cannot be linked back to individuals under any circumstances
Irreversibly de-identified
No Works Council requirement
Not subject to GDPR

Masked (pseudonymized) data:

Cannot be linked back without a key/mapping
Reversibly de-identified
Works Council requirement reduced (but not eliminated if masking is weak)
Subject to GDPR (still personal data)

Best practice for Salesforce:

Use deterministic pseudonymization (masking):

Employee "John Smith" → "Employee-7482" (consistent, but reversible with mapping)
This satisfies Works Council concerns (no identifiable performance tracking)
This satisfies GDPR (personal data minimization)

True anonymization (one-way, irreversible hashing) is harder to achieve and less practical for sandbox testing because you can't correlate data.

What if we have a partial sandbox with no employee data?

A: Then Works Council approval is not required.

If your partial sandbox refresh includes only:

Contacts (customers)
Accounts (prospects/partners)
Opportunities
Custom business objects (no employee fields)

And excludes:

Activity logs
Task records (if employee-assigned)
Email records
Custom employee metrics

Then there's no monitoring system and Works Council approval is not triggered.

How to ensure:

Use Salesforce's partial sandbox feature to exclude specific objects:

Exclude Activity
Exclude Task
Exclude Email
Exclude any custom employee performance objects

Document which objects are excluded for compliance records.

Do we need separate masking rules for different Salesforce objects?

A: Yes. Different objects contain different types of employee data:

Activity object: Mask all fields

OwnerId (who performed the activity)
DurationSeconds
Subject (may reference employee)
StartDateTime

Task object: Mask some fields

OwnerId (who owns the task)
Keep Subject (usually non-identifying)
Keep priority, status (workflow logic)

Contact object: Minimal masking needed

Mask Email (if internal employee contact)
Mask Phone (if traceable)
Keep Name (customer contact, not employee)

Custom Performance object: Mask all fields

Employee lookup
All metrics
All timestamps

DataMasker lets you define object-specific rules. German compliance best practice is to mask employee-identifying and performance-related fields while keeping business context intact for testing.

Next Steps

Audit your Salesforce data: Identify where employee performance data lives (Activity logs, custom objects, metrics)
Assess Works Council requirements: Does your org have a Works Council? Do sandboxes contain the data types listed above?
Choose your compliance strategy:
- Small org, minimal employee data → Consider negotiation + approval
- Large org, frequent sandboxes → Deploy masking
- Mixed approach → Masking + notification
Implement data masking: Deploy DataMasker or similar tool to sandbox refresh pipeline
Document for auditors: Create compliance policy and keep masking audit logs
Notify Works Council: Even if approval isn't legally required, transparency builds trust

Learn More

Explore DataMasker – Automated data masking for German compliance. Mask employee performance data in sandboxes to satisfy BetrVG Section 87(1) No. 6 requirements.

##### Saurabh Gupta

Saurabh is an Enterprise Architect and seasoned entrepreneur spearheading a Salesforce security and AI startup with inventive contributions recognized by a patent.

Share this article

Learn More About Cloud Compliance

Explore our native Salesforce data privacy products.

Book a Demo