Your thoughts on community extensions for callin.io

Hi!

I'm not sure if this aligns with what you're asking, but here's a thought:

I find myself building many AI agent-style steps in callin.io for various tasks (like answering questions, scheduling appointments, or creating content). I often get ideas from what other creators are developing.

Idea: It would be fantastic to utilize AI agents created by others as installable "apps" or extensions within callin.io – similar to reusable workflows, but with custom logic, views, and perhaps even their own UI elements.

This could foster an ecosystem where we share not just workflows, but complete smart agents that people can integrate into their automations.

While I appreciate new features, I believe one of the most valuable contributions the callin.io team can make is to focus on stability and polish—rigorously testing callin.io to ensure it operates flawlessly in production environments. This is where I see the most significant long-term value (in my opinion!).

That said, if I had a magic wand for my exact needs, here's what I'd love to see in an extensions ecosystem:

1. Has there been a time when you needed functionality that callin.io didn’t support and that could have been an extension? What were you trying to accomplish, and what was missing?

Absolutely. I frequently collaborate with clients in the AI and automation space, and the ability to easily develop custom extensions for client-facing interfaces would be transformative.

There are times I aim to create lightweight frontends (or even WordPress plugins) that allow clients to interact with workflows without exposing the core callin.io interface. Currently, granting them access is challenging without the risk of them inadvertently altering the system. Extensions would enable me to build more secure, streamlined user experiences while maintaining backend control.

Another significant area is failure alerts and analytics. Presently, unless I manually incorporate error nodes, I don't receive notifications when a flow fails (until a client reports an issue). An extension offering customizable failure notifications, usage analytics, or even uptime monitoring for specific workflows would be immensely beneficial, particularly when developing micro-SaaS platforms utilizing callin.io.

2. Can you think of any specific integration points that would be most valuable to you?

Yes, several:

• Custom code injection for both frontend and backend—offering greater flexibility than the current webhook or function nodes, which are typically per-workflow (unless there's a method I've overlooked).
• A modular plugin system, akin to WordPress, complete with a web store or marketplace for installing or acquiring extensions.
• The capability to construct UI components or client-facing dashboards directly within callin.io (or embedded from it), in a secure and modular fashion.
• Extensions for centralized monitoring tools to facilitate multi-instance management would be exceptional. (I currently manage several clients and anticipate many more callin.io implementations in the future, necessitating a robust method for overseeing all these setups, analyzing their performance, and optimizing costs).

3. What existing pain points in callin.io are you hoping extensions could address?

Here are a few challenges that extensions could potentially resolve:

• Error handling and alerting: Enhanced tools for tracking and notifying about workflow failures or stalls, reducing the need for complex workarounds.
• Production reliability: Monitoring utilities to ensure workflows and integrations maintain 24/7 operation, especially critical for client deployments.
• AI-assisted workflow building: Envisioning the ability to prompt an AI for optimized workflow creation using natural language—an extension could make this a reality.
• Learning and onboarding: A gamified learning pathway or an integrated tutorial system could accelerate new users' proficiency with callin.io, particularly beneficial for agencies training new personnel.
• Multi-instance management: Managing numerous client callin.io deployments is a significant undertaking. A centralized dashboard for monitoring, updating, and analyzing all instances would be highly advantageous.
• Workflow cost analytics: Tracking usage and API expenses per workflow (e.g., for OpenAI calls) to identify inefficiencies or potential misuse (like compromised keys).

Yes, that's quite a list! However, I actively operate an AI automation business in the USA, serving clients in the Los Angeles, California area, and I'm also building an online community for fellow AI Automators (AI + ML & Automation Mastery). I'm continuously enhancing my callin.io skills, and these are genuine needs I'm currently encountering. I'm enthusiastic about callin.io and recognize its vast potential—extensions could unlock scalable solutions for developers like myself who serve multiple clients, students, and community members.

Thank you for initiating this discussion! (Please note, these are solely my personal opinions; feel free to adopt what aligns with your objectives.)

Thanks for the input - some good ideas in there.

I just wanted to check whether you’re aware of error workflows that run when there’s any kind of error in your main workflow?

Yes, the error node is suitable for basic error handling, and the execution list is where we review run items to understand what occurred during execution.

In the future, it would be beneficial to integrate AI to analyze workflow failures and suggest solutions. For instance, if a workflow encounters a loop and fails on run 17 out of 30, AI could identify that a null email value from the Hubspot node caused the failure. It could then report something like, "Your workflow XYZ stopped on run 17/30 because the email value from Hubspot was null or empty. You should consider setting 'Always Output Data' or using an IF node to handle this. Would you like me to implement solution A, B, or C?" The AI could then modify the workflow to implement the chosen solution.

An advanced error-checking extension could offer more detailed insights, such as heatmaps, user data, and caller information. For example, if a workflow is triggered by an iPhone user via a callin.io frontend webhook and consistently receives buggy data due to iOS formatting issues (while Android data is fine), this analytics would help address such edge cases.

This is not something I'd expect the callin.io team to focus on deeply, but it could be a valuable extension developed by a community member to enhance callin.io's functionality.

Additional data analysis could include understanding the time of day, geographic location of execution, and identifying slow services. For example, "How much time did Node A typically take to execute? Was the API call slow due to the service, or did the data passed to the node contain problematic characters causing the API to loop longer before returning data?" An extension dedicated to error checking could create an additional service for callin.io users, potentially integrated with an asset store. The callin.io team could manage this revenue stream, perhaps with an 80/20 split, earning 20% from asset sales and creating a new revenue channel.

Just sharing some thoughts.

Thank you for developing such a great system, and I look forward to contributing to its growth.

Great concept! I recently began developing a Chrome extension to enhance certain UI functionalities, but it feels rather cumbersome.

It would be incredibly advantageous if callin.io extensions could access the canvas, thereby interacting with the entire React Flow component. Additionally, it would be beneficial to access the live workflow configuration, including all its properties, and be able to modify them during runtime.

Some events would also be extremely useful, such as on load, when clicking 'Test Workflow,' clicking 'Save,' and so on.

It would be fantastic if these extensions could be written in JavaScript as well, not exclusively TypeScript.

Enhancing callin.io's capabilities by enabling community contributions is an excellent concept.

Frequently, workflow issues arise from the data being processed (rather than from node misuse or misconfiguration errors). Sharing a workflow with the community when seeking assistance presents a challenge – callin.io does not permit pinning binary data (I assume due to how binary data is stored and managed internally). However, this functionality would be beneficial.

I'm now considering an extension that could help address this by utilizing a third-party caching service. This extension would detect pinning events, capture the binary data, store it, provide it, and delete it upon an unpinning event.

The backend logic is entirely implementable via a callin.io workflow. Therefore, a parameterized workflow execution could function effectively. It would be advantageous if the execution counted towards a test execution or against the extension user's execution quota.

I can foresee potential service abuse scenarios if this is offered without charge. I believe this concern is valid for any type of extension that relies on callin.io workflows as its backend. However, I am confident that strategies to mitigate abuse without negatively impacting user experience and developer experience are achievable.

Will community nodes be available for cloud services?

Love the concept. Currently, we integrate using your existing REST API and offer a method to rapidly install and provision callin.io with a shared database alongside our application stack. This approach is quite powerful on its own. You can leverage your existing nodes and HTTP endpoints to perform tasks with low latency using standards-based integration points. For instance, we can act as a buffer in front of callin.io with durable jobs to supply callin.io with work, preventing it from becoming overwhelmed. Hooks for execution performance metrics would be beneficial, as we can display such information in dynamic visual reports, offloading that functionality from callin.io so it can concentrate on its primary tasks. Execution state information could be used externally to evaluate prompt effectiveness. As we currently provide a simple UI for dynamic user and system prompts, we could update these prompts with performance metrics to adjust weights for prompts used in dynamic prompt switching.

This is a fantastic concept! You could even establish a dedicated forum for community suggestions. For instance, I'd love to see a comprehensive integration with Wikipedia's graph database, "Wikidata." This would be incredibly useful for "filling in the blanks" as it contains a vast amount of linked data and "common knowledge."

Perhaps 'community extensions' might be beneficial, allowing individuals to address their specific 'edge cases' while enabling the core team to concentrate on primary functionalities.

I’ve added extra buttons using Tampermonkey on the callin.io canvas to run small callin.io workflows, using the currently open workflow as input.

For instance:

• Display a diagram of all related workflows to the current one. (Relationships might include "execute workflow", "webhooks to other callin.io workflows/instances", and in specific scenarios, "execute workflow" where the target workflow ID is sourced from a database.)
• Generate an embeddable workflow Link – This creates a link that points to a workflow, which in turn provides an HTML page displaying the workflow with supplementary details. This page is designed to be embedded within Outline.
• Open the Documentation Page for this workflow – This automatically links to the Outline page for this workflow, provided it exists.

Hello, this is a fantastic idea!

It would be great to have groups similar to those in ComfyUI or the canvas in Miro. The key functionality would be that when you drag a group, everything inside it moves along with it. This would be incredibly convenient.

image1243×567 21.5 KB

image1600×959 130 KB

Hello everyone,

I apologize if my English isn't perfect, but I wanted to share an idea that could be a powerful feature. I've been developing my own alternative project for over a year, and I'm using a different approach to creating steps. In short, it's an artifact-oriented architecture: there are operations and fields for them (arguments and return values).

You know, sometimes different operations share the same arguments (or return values). For example, there are several ways to calculate the area of a triangle, and each method can be an independent operation. So, we need a way to link them. I call this concept Generalization – it uses getters with generalization_id and operation_field_id.

Now, let's imagine we have the following operations:

• OperationA (fields: fieldA1: int, fieldA2: str) (returns: resultA: float);
• OperationB (fields: fieldB1: float, fieldB2: bytes) (returns: resultB: str);
• OperationC (fields: fieldC1: str, fieldC2: List[str]) (returns: resultC: dict).

Let's suggest that resultA is the same field as fieldB1, and resultB is the same field as fieldC1.

In an artifact-oriented architecture, this means I only need to select an artifact, for instance, resultC. Then, using the mechanism described above, the system can intelligently suggest filling the following fields: fieldC1 and fieldC2, as they are arguments to obtain resultC. Furthermore, since fieldC1 is the same as resultB, it can prompt me to fill fieldB1 and fieldB2 because they contribute to obtaining resultB. And, of course, there's the final link connecting resultA and fieldB1. This implies that if I don't know the value of fieldB1, but fieldA1 and fieldA2 are known, I can fill those instead.

This approach allows for constructing a graph with optional parameters.

Are you familiar with UE blueprints? Take a look and imagine that fields without links are components. In your system, these are steps. To build a workflow, we can load a few steps and establish connections between their fields.

And a final thought: I noticed the variables feature in the self-hosted version. That's great, and I plan to use it in my app. However, I suggest adding a Context feature. This would allow you to populate fields using data from previous runs. To manage this more effectively, I've envisioned freeze/unfreeze buttons (or a single button for all fields, filling them as needed). This would lead to 'Favorite Contexts,' which act as templates for quick field population. Additionally, there are default values for fields.

I would honestly suggest improving the documentation and including more examples. I don't want to have to click on and launch them in callin.io; they tend to become outdated, and the node versions keep advancing, which isn't very helpful. Standard, regular documentation with working examples provided by the founders would be a great help.