Infor Syteline — now sold as Infor CloudSuite Industrial — is built for multi-site SMB manufacturers running engineer-to-order, make-to-order and repetitive production. Its flexibility is the attraction: you can extend forms, add tables and create IDOs to fit how you actually work. But every customisation is another place where access rights sprawl, and segregation of duties gets harder to hold onto. This article covers where SoD conflicts arise in Syteline, how to use its role model and approval flows to prevent them, and what to review once you are live.
For why segregation of duties matters in an ERP environment, see our complete guide.
SoD in Infor SyteLine
Infor SyteLine is Infor’s ERP solution that addresses business and operational challenges for (bigger) SMB manufacturing (multi-site) companies. Supported business models include Engineer-to-order (ETO), Make/configure-to-order (MTO/CTO), Make-to-stock (MTS), Repetitive Manufacturing and Service management.
It supports all end-to-end business processes with comprehensive functionality, including finance, supply chain, manufacturing, project management and service management. SyteLine allows the user to extend and adapt the application by extending and adding forms, extending the database schema and creating tables, extending and creating IDOs (business logic objects).
Flexible definition of user roles and permissions allows companies to implement SoD policies and ensure no single user has control over all aspects of a critical business process.
Examples for SoD in Infor SyteLine
- Finance: In the finance module, SoD can be implemented by separating roles such as invoice creation, approval, and payment processing. For example, one user might be responsible for entering supplier invoices, another for approving them, and a third for processing payments. But also in maintenance of master data, SoD can be important, such as maintenance of supplier bank account information which is incompatible with processing payments.
- Procurement: In the procurement module, SoD can be achieved by segregating tasks such as purchase order creation, goods receipt, and vendor payment. This ensures that no single user can complete the entire procurement cycle without oversight.
- Manufacturing: In the manufacturing module, SoD can be applied by separating roles such as production planning, execution, and quality control. This helps to ensure that production processes are carried out accurately and efficiently.
Implementing SoD in Infor SyteLine
- Access Control: Infor SyteLine enables organizations to define user roles and access rights based on responsibilities. Access can be restricted at various levels, including subsets of the data. This enables organizations to ensure that users only have access to the functions and data they need to perform their jobs.
- Approval flows: Infor SyteLine allows organizations to define automated workflows to support SoD by routing tasks and information automatically to users. For example, certain purchase orders might require approval from a manager before they can be processed.
- Audit Trail: Infor SyteLine provides audit trail functionality, which can log user activities and changes to the system. This helps organizations monitor compliance with SoD policies and identify risks.
- Regular Reviews: Regular reviews of user roles and permissions are essential to ensure that SoD controls remain effective. Dynaflow allows organizations to generate reports on user roles and access levels, which can be used for periodic reviews.
- SoD Conflict Scans: Regular scans to identify, report and mitigate SoD conflicts when they occur. Dynaflow allows organizations to automate scans directly on Infor SyteLine data and supports the workflow-based resolution of SoD Conflicts.
Mitigating conflicts you cannot remove
In a mid-sized manufacturer there is often nobody to hand the second task to. A finance controller may genuinely need to maintain supplier bank details and release payment runs, because the department is three people. Removing the access stops the work. Leaving it unaddressed fails the audit.
The answer is a mitigating control: the access stays, and you add evidence that it is not being misused. Syteline gives you four mechanisms, and they are worth trying in this order.
- Narrow the access before you monitor it. Syteline can restrict access at the level of data subsets, not only whole forms. A controller who needs to see supplier records across the business may only need to change them for one site or one legal entity. Narrowing scope reduces the exposure before any control is needed, and it is cheaper to run than monitoring.
- Force a second pair of eyes through an approval flow. Where the conflicting activity is transactional, route it. An approval flow that sends any change to supplier bank details to a second person for confirmation reinstates the separation at the moment it matters, without touching the role. This is the strongest of the four, because it prevents rather than detects.
- Make the activity visible in the audit trail. Turn logging on for the activities named in the conflict rather than for the whole system — a log nobody reads is not a control. For the bank-details example, capture who changed the field and when, then review those entries against the payment runs that followed them.
- Review the exception on a schedule, and write down who owns it. A mitigating control that exists only in someone’s memory fails at the first audit. Record which conflict it addresses, what evidence it produces, who reviews it and how often. Then re-check whether it is still needed after any role change.
Two things auditors consistently ask for and companies consistently cannot produce: the link between a specific mitigating control and the specific conflict it mitigates, and evidence that the control was actually performed. Both are far easier to design in at the start than to reconstruct under audit.
For how mitigating controls fit alongside removing and restricting access, see Part 4 of our complete guide to segregation of duties in ERP.
Challenges and Solutions
Implementing SoD in an ERP environment like Infor SyteLine can be challenging due to the complexity of business processes and the need for extensive configuration. However, these challenges can be mitigated by:
- Comprehensive Planning: Developing a detailed SoD plan that outlines roles, responsibilities, and workflows.
- Predefined User Roles: Infor SyteLine includes a comprehensive set of predefined user roles and permissions based on best practice SoD policies. Using these roles as a starting point for SoD planning dramatically reduces implementation effort.
- Training and Awareness: Ensuring that implementing teams understand the importance of SoD and are trained on how to comply with SoD policies. Conflicts can be identified using Dynaflow conflict scans.
- Continuous Monitoring: Using Infor SyteLine’s audit trail and reporting features in combination with Dynaflow to continuously monitor compliance with SoD policies.
Conclusion
Separation of Duties is essential for maintaining the integrity and security of business processes in an ERP environment like Infor SyteLine. By implementing effective SoD controls, organizations can mitigate risks, ensure compliance, and maintain data integrity, ultimately enhancing overall operational efficiency.
For the full method — role design, conflict detection, triage and ongoing control — see our complete guide to segregation of duties in ERP