---
title: "IFS Cloud functionality and Workflows"
date: 2026-01-07
description: "Before authorizing a developer to write custom code, the solution architect should always ask: Can this be achieved via Workflow?"
author: "Dariusz Mysliwiec"
categories:
  - name: "Blog"
    url: "https://www.ifs-erp.com/blog.md"
tags:
  - name: "Configuration"
    url: "https://www.ifs-erp.com/tags/configuration.md"
  - name: "Customization"
    url: "https://www.ifs-erp.com/tags/customization.md"
---

# IFS Cloud functionality and Workflows

The "Workflow First" Philosophy

 At IFS-ERP.com, we advocate for a **"Workflow First"** mindset. Before authorizing a developer to write custom code, the solution architect should always ask: *Can this be achieved via Workflow?*

 ### Configuration vs. Customization

  

 Implementation

 **Old Way:** Requires Developer (C#/PLSQL)  
  
**New Way:** Requires Functional Consultant

  

 Visibility

 **Old Way:** Hidden in code files  
  
**New Way:** Visual Flowchart (BPMN)

  

 Maintenance

 **Old Way:** High (Code reviews, compile times)  
  
**New Way:** Low (Adjust and Publish)

  

 Upgrade Risk

 **Old Way:** High (Breakage likely)  
  
**New Way:** Low (Forward compatible)

 ### When Customization Is Still Necessary

 While Workflows are powerful, they are not a silver bullet. There are specific thresholds where configuration ends and "Extensibility" begins.

  

 1. Deep System Integrations

 For complex encrypted bank files or high-frequency machine interfaces, standard workflows may fall short.  
  
Verdict: Use custom projections or integration middleware.

  

 2. Performance-Heavy Logic

 Looping through 50,000 records to perform a nightly calculation via workflow is significantly slower than PL/SQL.  
  
Verdict: Use heavy server-side logic for bulk data processing.

  

 3. Unique Complex Algorithms

 If a business rule results in a BPMN "spaghetti diagram," it becomes impossible to maintain.  
  
Verdict: Encapsulate the complex logic in code, and call it from a workflow.

 Frequently Asked Questions

 #### Optimizing for the Evergreen Era

 Understanding the distinction between **Configuration** and **Customization** is vital for maintaining a healthy IFS Cloud environment.

 Utilizing the native **Workflow Engine** ensures your business logic remains intact during bi-annual releases, reducing the "Technical Debt" that traditionally plagues ERP upgrades.

 What is the difference between IFS Configuration and Customization?

 **Configuration** uses native tools like the Workflow Manager to alter system behavior without code changes, ensuring upgrade safety. **Customization** involves modifying the core source code (PL/SQL, C#), which carries higher maintenance costs and upgrade risks.

 Do I need a developer to create IFS Workflows?

 **No.** IFS Workflows utilize BPMN (Business Process Modeling Notation), a visual low-code standard. This allows Functional Consultants and Business Analysts to design and implement complex processes visually, without writing traditional code.

 Are IFS Workflows safe for upgrades (Evergreen)?

 **Yes.** Workflows are stored as configuration data (XML models) separate from the core codebase. This makes them inherently "Evergreen" compliant, meaning they automatically migrate during IFS Cloud updates with minimal risk of breakage.

 Can Workflows replace all customizations?

 **Not all.** While they handle internal logic, data validation, and user interaction excellently, high-performance tasks (like bulk data processing) or complex external integrations (heavy bank files) are still better suited for specialized Customizations or IFS Connect.

 Summary

 IFS Workflows represent the maturation of the ERP landscape. They empower organizations to own their business processes without incurring the "technical debt" associated with traditional customization.

 **By adopting a "Workflow First" strategy, you adapt your ERP to your business, rather than adapting your business to your ERP.**