Make needs to put some focus on or clarify the security aspect in its documentation or website. When creating automation through these modules between two different applications, there should be clarity about whether the data is secure while passing through these automations or integrations created within Make. The pricing of Make at this point is through operations consumption, and it becomes really expensive in certain scenarios when iterations are involved. The operation consumption is too high and sometimes becomes a burden on the client. Make needs to review its pricing strategy since they have tough competition from n8n. Make sometimes has issues with user logins and data saving when simultaneously working on two different PCs or when two developers are working on something or some blueprint. It can lose saved data from one interface to the other, and when logging on with the same user on another workstation, it occasionally misbehaves. We were unaware that Make had its own local implementation module. They need to advertise this feature more effectively as we are developing many projects in Make and working with various clients.
I don't think there's anything else Make needs, but one improvement could be the addition of no-code steps that can be used within Make, similar to what Zapier offers with its own actions.
Make has a single IP. We cannot use a single IP because of the security. There are a lot of crashes when you work manually. Also, they need to provide more models. When you have an error, Make should inform them with guidance before you make the mistake. There is a lot of data you can confuse.
Make could improve the ease of use, it can be more complicated than other solutions. There are a lot of elements that are more technical than in other solutions.
Process Automation streamlines operations by reducing manual intervention, enhancing efficiency, and ensuring task consistency. It integrates seamlessly into existing workflows to optimize productivity.Businesses utilize Process Automation to achieve high levels of accuracy in repetitive tasks. Automation solutions decrease workload pressure, allowing employees to focus on higher-value activities. This technology ensures quicker processing times and enhances overall performance within diverse...
Make needs to put some focus on or clarify the security aspect in its documentation or website. When creating automation through these modules between two different applications, there should be clarity about whether the data is secure while passing through these automations or integrations created within Make. The pricing of Make at this point is through operations consumption, and it becomes really expensive in certain scenarios when iterations are involved. The operation consumption is too high and sometimes becomes a burden on the client. Make needs to review its pricing strategy since they have tough competition from n8n. Make sometimes has issues with user logins and data saving when simultaneously working on two different PCs or when two developers are working on something or some blueprint. It can lose saved data from one interface to the other, and when logging on with the same user on another workstation, it occasionally misbehaves. We were unaware that Make had its own local implementation module. They need to advertise this feature more effectively as we are developing many projects in Make and working with various clients.
I don't think there's anything else Make needs, but one improvement could be the addition of no-code steps that can be used within Make, similar to what Zapier offers with its own actions.
Make has a single IP. We cannot use a single IP because of the security. There are a lot of crashes when you work manually. Also, they need to provide more models. When you have an error, Make should inform them with guidance before you make the mistake. There is a lot of data you can confuse.
Make could improve the ease of use, it can be more complicated than other solutions. There are a lot of elements that are more technical than in other solutions.