MAKE has been going downhill with these recent updates

[Mr.Make]

It’s been taking extremely long to load into both the scenarios page and the org page recently—especially when moving from a scenario and clicking the back button next to the name. Overall, performance and usability feel like they’ve gone downhill after the recent updates.

On top of that, the UI updates have been very frustrating:

1. The operation count on modules is now barely visible and much harder to open.

2. In History, showing the execution ID as the main run name feels unnecessary and confusing.

3. Displaying credits on every run clutters the interface. Credits should only appear when multiple are consumed (e.g., AI calls). Otherwise, it’s just wasted space.

4. Just way more bugs then there used to be. You can see from the screen shot we moved away from operations and using credits now. But it shows 0 credits and only operations. Like get it straight.

These changes make the platform slower, less intuitive, and harder to use compared to before.

My main issue is performance. It also seems like the team is just throwing unless UI updates. Lets focus on the main features. Like the entire theme of the platform just seems to be moving off.

[Greatness_me]

Hello @Mr.Make , you are correct. I’ve noticed a major decrease in the make website’s performance since their most recent updates. But I’m sure their team is putting in a lot of efforts to fix it.

[alfasi.hanni]

Thank you for posting this! I thought I was going crazy when I saw those hash strings appear in my execution history.

The Run ID column is a textbook example of over-engineering the user interface. It takes up space, adds no value, and makes everything harder to read. Classic case of showing users the plumbing instead of focusing on the experience.

I manage automation workflows for multiple clients and this change has made my daily reviews noticeably more frustrating. Instead of a clean chronological view, I now get a column of gibberish that I have to ignore.

The positioning makes it even worse - putting it first suggests it’s the most important piece of information, when it’s actually the least relevant to human users.

Starting to worry about the direction Make is heading with these UI decisions. The platform’s strength was always its intuitive interface, but these recent changes feel like steps toward making it more complex rather than more user-friendly.

Fingers crossed for a quick revert or at least an option to hide unnecessary columns.

[Gilad_Scher]

Adding another voice to this frustration!

The Run ID situation is a perfect example of what’s wrong with these recent updates. I manage multiple client accounts and this change has made reviewing execution history significantly more cumbersome.

Before: Quick scan of Started times, immediate status visibility, clean workflow overview Now: Wall of meaningless hash characters that I have to mentally filter out to find actual useful information

It’s a basic UX principle - don’t expose internal system data unless users specifically need it. The Run ID serves zero purpose in day-to-day scenario management. It’s like showing customers the order tracking numbers but hiding the actual delivery dates.

What’s particularly annoying is that this seems to be part of a pattern where Make is adding complexity rather than simplifying. The interface feels increasingly cluttered with information that benefits the system rather than the user.

Would love to see some user research data on whether ANYONE actually wanted this Run ID prominently displayed. My guess is the answer is zero.

Make team - please consider user workflow first, technical convenience second.

[Ram_Moshkovits]

Exactly this! I’ve been pulling my hair out over that new Run ID column that appeared in the execution history.

Started noticing it today across all my scenarios - these long hash strings like “ae5e8442c31349afbd9019…” taking up prime real estate in the first column. It’s completely useless information for anyone actually trying to manage their workflows.

The irony is that this internal identifier was already accessible if you clicked into the execution details, which is exactly where it should stay. Now it’s front and center, making the whole interface look like a developer debug panel instead of a user-friendly automation platform.

It’s particularly frustrating because the Started timestamp - which is actually critical for understanding when things ran - gets pushed to the second column. That’s backwards priority design.

Really feels like Make is prioritizing their internal data structures over user experience. We need workflow-focused interfaces, not technical implementation details cluttering up our daily views.

Hope this gets rolled back soon or at least made optional. The old layout was so much cleaner and more functional.

[aderet_trachtingot]

Completely agree with this assessment! The execution ID/Run ID being moved to the main execution history table is driving me crazy too.

I’m seeing this across multiple accounts and zones - that cryptographic hash (like “74aadcceaa8b4f78af95ccf…”) now takes up the entire first column where it serves absolutely zero purpose for daily workflow management.

The Run ID was perfectly fine buried in the execution details where it belonged as internal system data. Now it’s the most prominent piece of information in the table, pushing actually useful info like Started time to secondary positions.

What we actually need to see at a glance:

• Started time (most important for chronological reference)

• Trigger/Activity type

• Status

• Duration, Operations, etc.

What we DON’T need cluttering the main view:

• Internal database identifiers that only matter to Make’s backend systems

This feels like a classic case of exposing technical implementation details to end users who have no use for them. It’s like showing users the internal record IDs from your database instead of meaningful display names.

The fact that the official documentation at https://help.make.com/scenario-history still shows the clean layout without this Run ID column suggests this wasn’t properly thought through.

Really hoping the Make team can either:

1. Add a toggle to hide system-level columns

2. Revert Run ID back to execution details only

3. Make column order/visibility customizable

These kinds of changes are exactly what’s making the platform feel less user-friendly. Focus should be on workflow efficiency, not database dump displays.

Anyone else experiencing this Run ID column issue? Let’s get some visibility on this specific problem.

[Lisa_Kleinman]

Hey everyone,

Lisa here, I run our Product Design organization at Make, and I wanted to share my thoughts.

First, I’m really grateful for the direct feedback. Make is only successful when it works well for you, and I want to acknowledge that some of the recent updates haven’t landed the way we hoped.

There are a few different themes coming up across the posts, and before diving into the specific features, I want to address the bigger issue. A lot of you have said that recent updates feel out of touch with what you actually need day-to-day, or that they add more friction than value.

That kind of feedback is tough to hear but incredibly important, because if we’re not making your work easier and more efficient, then we’re missing the mark. You’ve all been incredibly generous with sharing your improvement ideas, and your posts have already sparked a lot of conversations inside Make about what we need to do differently and better.

With that in mind, I’d like to walk through a few of the specific areas you’ve called out. The responses below also include input from Product Managers, Designers, and Engineers who discussed each of these with me.

Execution history/RunID
Our goal with showing RunIDs is to let you change it, creating your own unique label to identify specific executions more easily. In internal testing, people found it helpful for troubleshooting. We agree that surfacing a long, unreadable string wasn’t the right first step, that’s on us and it shouldn’t have happened.

We’re reverting this change now and we’re working on a better, human-friendly solution. Vojtech Pavelka, the designer on my team, would be happy to discuss this with anyone further. You can book a meeting directly with him here.

(continued in next post)

[Lisa_Kleinman]

Credits/Operations
The new credits visual design is flexible to every customer’s preference, you can toggle visibility on or off from the scenario title bar (see the image below). I hear your feedback that it feels unnecessary in most workflows outside of AI, but that’s not true for everyone.

The way we designed operations & credits came from our customer interviews. We found there were two mindsets: about half wanted to see every detail of credits used (even outside of AI pricing), while the other half only cared about operations. That’s why we built the toggle, so you can personalize the view to match what matters most to you.

Performance issues
We know stability and speed are non-negotiable. We would like to assure you that we actively monitor key performance and reliability indicators and make improvements on a continuous basis. Performance, in particular, is a complex topic that touches many layers of the product, including the workflow execution but also the user interface.

Since Make is a very flexible platform that allows users to be very creative in terms of what type and complexity of workflows they can design, there may be particular situations or use cases with room to optimize. We would be very happy to hear from you if you come across a place in the product or a particular use case where you perceive low performance. It would help us prioritize what to optimize first, in order to make you more productive. In the meantime, please keep flagging when and where you’re seeing issues, it helps us track patterns and address them faster.

Keep being loud about what’s not right in Make. And reach out anytime.

-Lisa

[Mr.Make]

Wow this is the kind of response that makes me love make even more than I do. My name is Mr.make lol. But on a serious note this is incredible would love to share and help where needed. This is the type of response from a leader that creates an amazing culture and company. Really, thank you!

[aderet_trachtingot]

@Lisa_Kleinman Thank you for such a thoughtful and comprehensive response! This is exactly the kind of leadership and responsiveness that makes Make.com special.

The quick commitment to revert the Run ID column shows you’re listening to real user workflows, not just internal metrics. I appreciate that the original intention was to enable custom labeling - that actually sounds useful when implemented properly.

Looking forward to seeing the human-friendly solution when it’s ready. The direct access to Vojtech for design discussions is a great touch too.

This response gives me confidence that Make.com prioritizes user experience over technical convenience. Thank you for taking the feedback seriously and acting quickly.

[Ram_Moshkovits]

Really appreciate the transparency and quick action on the Run ID issue!

It’s reassuring to know that the original intent was to enable custom execution labeling - that could actually be quite valuable when done right. The current implementation with cryptographic hashes definitely wasn’t user-friendly, so thank you for acknowledging that misstep.

Since you mentioned “we’re reverting this change now,” I’m hoping this means we’ll see the Run ID column disappear from execution history fairly soon? The current state makes daily workflow reviews quite cumbersome, so any timeline guidance would be helpful.

The offer to connect with Vojtech for design input is excellent - shows you’re serious about getting the user experience right the second time around. Looking forward to seeing how the human-friendly solution evolves.

Thanks for listening to the community feedback so directly and acting quickly! @Lisa_Kleinman

[alfasi.hanni]

This response perfectly demonstrates why Make.com has such a loyal user base - you actually listen and respond to real workflow needs!

The Run ID situation is a great example of how good intentions (custom labeling capability) can go wrong in execution (exposing internal system identifiers). Your acknowledgment that “surfacing a long, unreadable string wasn’t the right first step” shows you understand the core UX principle: technical implementation details shouldn’t become user-facing friction.

What I find most encouraging is your commitment to developing a “human-friendly solution” rather than just abandoning the feature entirely. Custom execution labeling could be genuinely useful for troubleshooting - it just needs to be designed from the user’s perspective, not the database’s perspective.

Really hoping to see that revert happen quickly so we can get back to efficient execution history reviews. Thanks for prioritizing user workflow over internal convenience!

[Gilad_Scher]

Thank you for addressing the Run ID column issue so directly!

As someone who reviews execution history multiple times daily, that wall of cryptographic hashes was genuinely impacting my productivity. Having to mentally filter out weird strings to find actual useful information like timestamps was frustrating.

Your explanation about the intended goal (custom labeling for easier identification) makes perfect sense - that would actually be valuable for troubleshooting complex scenarios. The execution just missed the mark by exposing raw system identifiers instead of user-friendly labels.

I’m particularly relieved to hear “we’re reverting this change now” because the current state makes the execution history feel more like a database admin panel than a workflow management tool. Looking forward to seeing the interface return to its clean, scannable format while you develop the proper solution.

This kind of responsive product management is exactly why Make.com maintains such strong user satisfaction. Thank you for the quick action!

[Lisa_Kleinman]

I just want to say thank you for the positive responses. It means a lot to know that the transparency and dialogue are helpful.

@Mr.Make and anyone else who wants to share more directly with me, my calendar is bookable here. And DM me if these slots aren’t friendly to your time zone, we can coordinate something that will work for you.