I’ve been in a very similar situation before, and what really helped me was realizing how Create and Change work in terms of state. The moment I understood that objects and associations stay in memory until they are committed, and only move to the database after a commit, a lot of things started to click for me. That was my first real “aha” moment. Once that part was clear, it became much easier to build the rest of the microflow logic on top of it and understand why certain steps were needed.

Because of that, I’d say it’s completely normal to experience this kind of confusion at the beginning. Another thing I’d recommend is trying not to rely too much on copy-paste at first. Instead, try to build the microflow on your own, even if it feels slower. When you get stuck, feel free to post it here. The community is always happy to help, and we’re more than ready to support you.

My background is in programming (.Net C# specifically), and I’ve found microflows very intuitive because they’re essentially a visual representation of methods.

They sit outside of “classes” in the traditional sense, but in Mendix the closest equivalent to a class is often an entity in the domain model.

When you use Create, you’re effectively instantiating a new object of that entity type. You then set its attributes (the equivalent of properties/fields in C# or Java), and once those values are set you can perform operations on the object, pass it to other microflows, return it, and finally commit it to persist it.

If you already have programming experience, thinking about microflows in this way helps a lot. Tthere’s very little difference conceptually, aside from the fact that the logic is represented visually.

Entity - Class

Mendix Entity: Order

C# Class:

public class Order
{
    public string OrderNumber { get; set; }
    public decimal TotalAmount { get; set; }
    public string Status { get; set; }
}

• Entityy - Order
• Attributes - OerderNumber, TotalAmmount, Status
• Object Instance - one Order object in memorty

Microflow - Method

Mendix Microflow: MF_CreateOrder

C# Method:

public Order CreateOrder(string orderNumber, decimal totalAmount)
{
    // Create Object
    var order = new Order();

    // Change Object (set attributes as neededd)
    order.OrderNumber = orderNumber;
    order.TotalAmount = totalAmount;
    order.Status = totalAmount > 1000 ? "High Value" : "Normal";

    // (optional) Commit Object - Commit Activity in Mendix
    SaveOrder(order);

    // Return value - red dot at the end of the MF in Mendix where you can set the terun value
    return order;
}

Create Object - New

Mendix: Create Object (Order Entity)

C#:

var order = new Order();

And as per previous unswer, the object exists in memory only until saved. 

Now, the same principle applies to Change Object or Decisions in Mendix - at the end of the day its just an If/Else statements in C# or Java or any other language. 

if (order.TotalAmount > 5000)
{
    order.Status = "Needs Review";
}
else
{
    order.Status = "Approved";
}

hi,

You’re actually in a very normal place for someone early in their Mendix career — almost everyone goes through this phase.

Being able to build microflows is different from truly understanding them, and that confidence usually comes only after working on a few real apps and debugging your own logic.

A few things that really help:

• Read microflows top-to-bottom like a story
  
• Don’t think in widgets or actions. Ask yourself: What data comes in? What changes? What goes out?
• Pause on Create / Change activities
  
• For each one, explicitly check:
  • Which object is being used?
  • Is it new or existing?
  • Which attributes or associations are actually being changed?
• Use the debugger a lot
  
• Step through microflows and inspect variables after each action. This is where things really “click”.
• Rebuild simple flows yourself
  
• Take an existing microflow and recreate it in a small test app. Repetition builds intuition very fast.
• Focus on patterns, not syntax
  
• Most Mendix apps repeat the same patterns (retrieve → change → commit → refresh). Once those patterns are clear, complex flows become much easier to read.

Also, don’t worry about version differences (9 vs 10) at this stage — the microflow concepts are the same.

What you’re doing now (intermediate learning paths + real app exposure) is exactly the right approach. Confidence in Mendix usually comes after the second or third app, not the first.