6 Major Limitations of Permissions Management in IFS – And How to Work Around Them

During our first IFS Permissions Webinar, we explored six key limitations of IFS permissions management and discussed real-world workarounds, including Doppelmayr’s approach to site-specific access control. 

Below, we outline these six limitations and potential solutions to make IFS permissions management more efficient. 

1. No Standardized Permissions Methodology 

One of the biggest challenges in IFS is the lack of a proven methodology for structuring permissions. Unlike other ERP systems that provide clear role hierarchies, IFS allows full flexibility in how permission sets are created and applied. 

Challenges: 

• No fixed framework for structuring permission sets, leading to inconsistencies. 

• Customers must define their own approach to permissions management. 

• Overly complex or unstructured permission hierarchies make troubleshooting difficult. 

Workarounds: 

• Adopt a role-based approach: Define structured roles rather than granting permissions on an ad-hoc basis. 

• Avoid deep hierarchies: Multi-level permission sets can lead to confusion and unexpected access issues. 

• Use clear naming conventions: This makes it easier to manage roles, especially when updating permissions. 

Example from the Webinar: 

IFS customers have approached this issue differently, with some opting for modular, scalable role structures, while others have struggled with permissions growing out of control over time. The consensus from the webinar was that simplifying role structures and maintaining consistent documentation are key. 

In our next webinar on April 24th, we’ll go deeper into structuring IFS permission sets effectively. 

2. No Predefined Roles or Templates 

Unlike some ERP solutions that provide prebuilt role templates (e.g., "Accounts Payable Clerk" or "Sales Manager"), IFS does not offer process-based, predefined permission sets. 

Challenges: 

• Every IFS customer must create their own roles from scratch, which can be time-consuming. 

• The lack of standard templates means there is no "plug-and-play" option for permissions. 

• While IFS includes technical roles (such as login access and reporting permissions), it does not offer business function roles. 

Workarounds: 

• Manually develop permission sets internally, ensuring alignment with business processes. 

• Purchase or adopt predefined permission sets from consultants or external tools, such as IFS Permissions Manager. 

• Keep the number of end-user roles manageable: Too many roles can lead to confusion and higher administrative effort. 

Example from the Webinar: 

During the webinar, it was noted that finance and procurement teams often need to manually create their roles, unlike in other ERP systems where basic templates are available. Many customers end up recreating the same permission sets, leading to inefficiencies across different IFS implementations. 

3. Limited Consulting Support 

One of the frustrations among IFS customers is the lack of specialized consulting support for permissions management. While IFS and its partners provide technical support, there is little non-technical guidance on best practices for structuring permissions. 

Challenges: 

• IFS consultants primarily focus on technical setup rather than business-oriented role structuring. 

• Customers must either build in-house expertise or find third-party consultants. 

• Underestimating permissions setup can lead to delays and security risks. 

Workarounds: 

• Decide early whether to manage permissions internally or seek external expertise. 

• Dedicate internal resources to learning and maintaining structured permissions. 

• Engage with the IFS user community: Learning from other IFS customers can provide valuable insights. 

Example from the Webinar: 

Several participants shared their experiences of IFS not offering best-practice recommendations, making role structuring more difficult. The trial-and-error approach often leads to increased complexity in managing permissions over time. 

4. Updates Can Disrupt Permissions 

IFS updates, particularly in IFS Cloud, can sometimes change existing permissions without warning. This occurs primarily within projections, where previously set access levels are modified automatically. 

Challenges: 

• Some projections change from "Read-Only" or "Full" to "Custom", affecting access control. 

• Companies need to manually verify and adjust permissions after every IFS update. 

• Lack of automated tools to track changes effectively. 

Workarounds: 

• Monitor permission changes after updates: Pay attention to projections marked as “custom.” 

• Use clear naming conventions and document all permissions to track changes. 

• Test permissions thoroughly before going live after an update. 

Example from the Webinar: 

Projections can change unpredictably after updates. This requires manual intervention, making IFS updates resource-intensive for permission managers 

5. Missing Projections in Navigator 

One common frustration among IFS customers is that some projections are not visible in the Navigator. This means users may grant access to a module but still lack access to key pages. 

Challenges: 

• Some key projections cannot be granted via ‘Manage by Navigator’. 

• Users only discover missing permissions during testing or after go-live. 

• Requires manual debugging to identify missing projections.

Workarounds: 

• Conduct extensive user testing to uncover hidden access issues. 

• Use debugging tools (such as the Developer Console) to identify missing projections. 

• Invest in predefined permission sets to minimize manual adjustments. 

Example from the Webinar: 

A finance user might have access to voucher processing but get blocked when clicking “New Voucher”, because that projection isn’t included in the Navigator. This issue only surfaces during real-world testing, making troubleshooting difficult. 

6. Permissions Are Site-Neutral 

IFS does not allow different permissions for the same user across different sites. If a user has access to a function, they have the same access at all sites, making it difficult to implement site-specific security policies. 

Challenges: 

• Users cannot have varying levels of access per site. 

• Companies with multiple locations struggle with access control. 

• Unlike other ERP systems, IFS does not support per-site permissions. 

Workarounds: 

• Accept the limitation and manually monitor site-specific permissions. 

• Use the Doppelmayr approach: Create separate user accounts per site. 

• Consider licensing implications: Additional user accounts require extra IFS licenses. 

Example from the Webinar (Doppelmayr’s Approach): 

Doppelmayr solved this issue by creating additional so-called special user accounts for employees who need different access per site. While this approach adds complexity, it ensures that permissions are properly controlled per location. 

Conclusion 

Managing IFS permissions is complex, but with the right approach, organizations can overcome these limitations. By structuring roles carefully, testing thoroughly, and leveraging external expertise, companies can improve security, compliance, and efficiency. 

💡 Join our next webinar on April 24th for a deep dive into structuring IFS permission sets effectively.