Key Takeaways
- User permissions control who can view, edit, approve, and delete data within solar software platforms
- Role-based access control (RBAC) assigns permissions by job function — designer, sales rep, admin, installer
- Proper permissions prevent accidental data changes, protect customer information, and maintain audit trails
- Growing solar companies need granular permissions as teams scale beyond 5–10 users
- Permissions should align with your actual workflow stages — design, proposal, permitting, installation, O&M
- Missing or poorly configured permissions create compliance risks with customer data regulations
What Are User Permissions?
User permissions are the rules within a software platform that define what each user can and cannot do. In solar software, permissions control access to designs, proposals, customer data, financial information, and administrative settings. They determine who can create a new project, who can modify a design, who can send a proposal to a customer, and who can approve pricing changes.
As solar companies grow from a handful of people to teams of 20, 50, or 200+, uncontrolled access becomes a real problem. Without proper permissions, a junior sales rep might accidentally modify a finalized design, an installer might see confidential financial margins, or a former employee’s account might remain active with full access.
Permissions aren’t about restricting your team — they’re about preventing mistakes and protecting data. A well-configured permission structure means every team member sees exactly what they need and nothing they don’t.
How User Permissions Work
Most solar software platforms implement role-based access control (RBAC), where permissions are assigned to roles rather than individual users:
Define Roles
The administrator creates roles that match the company’s job functions: Designer, Sales Rep, Project Manager, Installer, Administrator, and so on.
Assign Permissions to Roles
Each role receives a specific set of permissions. Designers get access to design tools and equipment databases. Sales reps get proposal creation and CRM access. Admins get everything.
Assign Users to Roles
Each team member is assigned one or more roles. When they log in, the platform shows only the features and data their role permits.
Enforce at Every Action
The platform checks permissions before every action — viewing a project, editing a design, sending a proposal, changing pricing. Unauthorized actions are blocked.
Audit and Review
Activity logs track who did what and when. Administrators periodically review access patterns and adjust roles as the company’s needs change.
Common Permission Roles in Solar Software
Solar companies typically need these core roles, though exact names vary by platform:
Administrator
Complete access to all features, settings, and data. Can create/modify roles, manage users, configure integrations, and access billing. Typically limited to company owners and IT leads.
Solar Designer
Access to design tools, equipment databases, shading analysis, and permit document generation. Can create and modify designs but may not have access to pricing or customer financial data.
Sales Representative
Access to CRM, proposal creation, customer communication, and pipeline management. Can view designs but typically cannot modify them. May have access to pricing within approved ranges.
Project Manager
Access to project status tracking, scheduling, permitting workflows, and installation coordination. Can view designs and proposals, manage timelines, and update project stages.
When evaluating solar design software, check how granular the permission system is. A platform that only offers “admin” and “user” roles will become a bottleneck as your team grows. Look for platforms that let you customize permissions at the feature level — not just the role level.
Permission Categories
User permissions in solar platforms typically cover these functional areas:
| Permission Area | Examples | Why It Matters |
|---|---|---|
| Project Access | View all projects, view only assigned, create new | Controls data visibility across the team |
| Design Tools | Create/edit designs, view-only, approve designs | Prevents unauthorized design changes |
| Proposals | Create, edit, send to customer, approve pricing | Protects margin and pricing consistency |
| Customer Data | View contact info, edit records, export data | Compliance with privacy regulations |
| Financial Data | View costs, view margins, modify pricing | Protects competitive and financial information |
| User Management | Add users, modify roles, deactivate accounts | Controls who manages the permission system itself |
| Integrations | Configure API keys, manage CRM sync, enable exports | Prevents unauthorized data flows |
Least Privilege = Give each role only the minimum permissions needed to do its jobPractical Guidance
User permissions affect how every team member interacts with the platform. Here’s role-specific guidance:
- Start with predefined roles. Most solar software platforms provide default role templates. Start with these and customize based on your actual workflow rather than building from scratch.
- Review permissions quarterly. As roles evolve and team members change positions, permissions drift. Schedule a quarterly audit to ensure access still matches job functions.
- Deactivate departed employees immediately. When someone leaves the company, deactivate their account the same day. Don’t just change the password — fully remove access and revoke any API tokens.
- Limit admin accounts. Keep the number of administrator accounts to 2–3 people maximum. Every admin account is a potential point of exposure for company-wide data.
- Align permissions with workflow stages. Map your permissions to your project lifecycle. Designers need access during design phase, sales during proposal phase, operations during install phase. Use workflow automation to transition project access between teams.
- Create view-only roles for stakeholders. Executives, investors, or subcontractors who need visibility but shouldn’t modify anything get view-only access to specific project data.
- Document your permission structure. Write down what each role can and cannot do. This prevents confusion when onboarding new team members and provides a reference during audits.
- Test before deploying. When creating or modifying roles, test them with a test account before applying to real users. One misconfigured permission can block an entire team.
- Set pricing guardrails for sales reps. Allow sales reps to adjust pricing within a defined range (e.g., up to 5% discount) but require manager approval for larger changes. This speeds up sales while protecting margins.
- Separate proposal draft from send. Let reps draft proposals but require a review step before sending to the customer. This catches errors in pricing, design specifications, and contract terms.
- Control customer data exports. Limit who can export customer lists and contact information. This protects your customer database if a sales rep leaves for a competitor.
- Use territory-based access. In multi-region companies, restrict sales reps to seeing only projects in their territory. This prevents lead conflicts and keeps the pipeline organized.
Manage Growing Teams with Confidence
SurgePV’s solar design software includes role-based permissions that scale with your team — from 3 users to 300.
Start Free TrialNo credit card required
Real-World Examples
Small Installer: 8-Person Team
A residential solar installer in Texas started with everyone sharing a single admin account. After a sales rep accidentally deleted a finalized design and a junior designer sent an unapproved proposal to a customer, the company implemented three roles: Admin (owner only), Designer (3 users), and Sales (4 users). Designers lost the ability to send proposals; sales lost the ability to edit designs. Errors dropped to zero within the first month.
Mid-Size Company: 45 Users Across 3 States
A growing solar company operating in California, Arizona, and Nevada created territory-based roles so each state’s team only sees their own projects. The design manager reviews and approves all designs before they’re released to sales. Sales managers approve discounts over 3%. Monthly activity reports flag unusual access patterns — such as a user accessing projects outside their territory — for investigation. The permission structure reduced pricing errors by 60% and eliminated cross-territory lead conflicts.
Enterprise: 200+ Users with Subcontractor Access
A national EPC created separate permission tiers for full-time employees, subcontractor design teams, and financing partners. Subcontractors see only the projects assigned to them and cannot access customer financial information or company-wide pipeline data. Financing partners get read-only access to approved proposals and credit applications. Each tier has its own data retention and export policies.
Impact on Software Selection
When evaluating solar platforms, permission capabilities directly affect scalability and security:
| Capability | Basic Platform | Advanced Platform |
|---|---|---|
| Role Types | Admin and User only | Custom roles with granular permissions |
| Data Visibility | All users see all projects | Territory, team, or project-based filtering |
| Approval Workflows | None — anyone can send proposals | Multi-step approval chains |
| Audit Logs | None or basic login tracking | Full activity log with user, action, timestamp |
| API Access Control | Single API key for all | Per-user or per-role API tokens |
| SSO Integration | Not available | SAML/OAuth for enterprise identity management |
When choosing solar software, always test the permission system during your trial period. Create test accounts for each role your company needs and verify that each role can do what it should — and nothing more. Permission limitations are hard to work around later.
Frequently Asked Questions
What are user permissions in solar software?
User permissions are access controls that define what each team member can do within a solar software platform. They determine who can create designs, modify proposals, view financial data, send documents to customers, and manage settings. Permissions are typically assigned through roles (like Designer, Sales Rep, or Admin) rather than configured for each individual user.
Why do solar companies need role-based permissions?
As solar companies grow, uncontrolled access creates real problems: accidental data changes, pricing errors in proposals, customer data exposure, and confusion about who changed what. Role-based permissions prevent these issues by ensuring each person only accesses the features and data their job requires. They also create an audit trail that helps resolve disputes and satisfy data protection regulations.
How should I set up permissions for my solar team?
Start by mapping your team’s actual workflow: who creates designs, who builds proposals, who approves pricing, who manages projects. Create a role for each function with only the permissions that role needs (the “least privilege” principle). Limit admin access to 2–3 trusted people. Test each role with a test account before assigning it to real users. Review and update permissions quarterly as roles evolve.
About the Contributors
CEO & Co-Founder · SurgePV
Keyur Rakholiya is CEO & Co-Founder of SurgePV and Founder of Heaven Green Energy Limited, where he has delivered over 1 GW of solar projects across commercial, utility, and rooftop sectors in India. With 10+ years in the solar industry, he has managed 800+ project deliveries, evaluated 20+ solar design platforms firsthand, and led engineering teams of 50+ people.
Content Head · SurgePV
Rainer Neumann is Content Head at SurgePV and a solar PV engineer with 10+ years of experience designing commercial and utility-scale systems across Europe and MENA. He has delivered 500+ installations, tested 15+ solar design software platforms firsthand, and specialises in shading analysis, string sizing, and international electrical code compliance.