AI 對話紀錄  March 17, 2025

【AG-01】Developing Workflow System with AppGini

Q: I've been using AppGini as a rapid development tool for many years. It generates very sophisticated web app will comprehensive data input support. However, I'm thinking if the detailed yet still input-focused interface can be used for handling workflows (like record approval) in a typical small company or NGO. For example, in customized systems the manager can approve a record and lock it from further modification but in web app generated by AppGini there is no similar automation support. I wonder if AppGini generated app can be enhanced with third party tools without coding. I asked this because I'm consider using AppGini to develop systems for clients since it's highly cost effective. The only draw back is the lack of automation support.

---

A:

Key Points

• It seems likely that AppGini-generated apps can be enhanced for workflows like record approval using third-party tools without coding, but setup may require technical help.

• Research suggests using no-code workflow tools like Zapier or Microsoft Power Automate, after setting up a REST API for AppGini.

• The evidence leans toward initial API setup needing some coding, which might be a barrier for non-technical users.

Direct Answer

AppGini is great for quick web app development, especially for data input, but it lacks built-in support for workflows like record approval and locking, which are common in small companies or NGOs. However, you can enhance these apps with third-party tools without coding, though it might need some initial setup.

How to Enhance AppGini for Workflows:

• Set Up a REST API: You’ll need to integrate a REST API with your AppGini app, like the one from the AppGini API GitHub repository. This allows external tools to interact with your data. Note that setting this up might require technical expertise or hiring a developer, as it involves some configuration.

• Use No-Code Workflow Tools: Once the API is set up, use tools like Zapier (Zapier) or Microsoft Power Automate (Microsoft Power Automate) to create approval workflows. For example, when a record is created, these tools can notify a manager, who can then approve or reject it via a simple interface, updating the status in AppGini via the API.

• Manage Approvals Externally: This approach lets you handle approvals outside AppGini, locking records by changing their status, which can prevent further edits without coding in the app itself.

Unexpected Detail: While AppGini has hooks for custom coding, using no-code tools with an API offers a way to add complex workflows like approvals without writing code, which is a flexible solution for cost-effective client systems.

This method is promising for your needs, especially given AppGini’s cost-effectiveness, but be aware that the initial API setup could be a hurdle if you’re not tech-savvy.

---

Survey Note: Enhancing AppGini for Workflow Management

This note explores the feasibility of enhancing AppGini-generated web applications to support workflows like record approval and locking, particularly for small companies and NGOs, without requiring coding. AppGini, a rapid development tool known for generating sophisticated web apps with comprehensive data input support, lacks built-in automation for such workflows. The focus is on leveraging third-party tools to address this gap, aligning with the user’s goal of cost-effective system development for clients.

Background on AppGini and Workflow Needs

AppGini is designed for creating web database applications without coding, running natively on Windows and generating PHP-based apps compatible with servers supporting PHP 7.0+ and MySQL 5.6+ or MariaDB 10+ (AppGini Official Website). It excels in data entry and management, as evidenced by user reviews on platforms like Capterra (AppGini Pricing, Alternatives & More 2022 - Capterra), but lacks native support for advanced workflows like record approval, where a manager can approve and lock records from further modification. This is a critical need for typical small company or NGO operations, where processes like membership updates or expense approvals require such automation.

The user’s concern is valid: while AppGini is cost-effective, its lack of automation support could limit its applicability for customized systems requiring workflow management. The question is whether third-party tools can bridge this gap without coding, preserving the no-code advantage for client development.

Exploring AppGini’s Capabilities for Workflows

Initially, we examined AppGini’s built-in features to see if they support record-level workflows. The documentation and forums reveal that AppGini has user group and permission management at the table level, as shown in the screencast on “Managing access permissions for logged-in users” (Screen cast: Managing access permissions for logged-in users). However, for record-level control, such as locking approved records, the system relies on the concept of record ownership, tracked in tables like “membership_userrecords,” as discussed in forum posts like “Approval of records” (Approval of records - AppGini Community Forums). This suggests that custom logic, possibly via hooks, is needed to implement approval workflows, which contradicts the no-coding requirement.

AppGini’s hook system, detailed in the documentation (Hooks (AKA events) - AppGini Documentation), allows developers to customize behavior for events like inserts, updates, and deletes. For instance, hooks could set a status field to “approved” and disable edits based on that status, but this requires PHP coding, as seen in examples like modifying SQL queries for table views (Modifying the SQL query of the table view using hooks). Given the user’s preference for no coding, this approach is not viable.

Investigating Plugins for Workflow Support

Next, we explored whether AppGini plugins could provide no-code workflow solutions. Available plugins, listed in forums like “List of currently available AppGini plugins” (List of currently available AppGini plugins - AppGini Community Forums), include Mass Update, Search Page Maker, Calendar, and DataTalk, among others. The Mass Update plugin, for example, allows batch updates to multiple records, which could theoretically set a status field for approvals (Mass Update plugin for AppGini). However, it lacks specific features for individual record approval and locking, such as conditionally hiding edit buttons based on field values, which isn’t supported out of the box without coding.

The AppGini Helper website (AppGini Helper | Libraries for AppGini Professionals) offers libraries and plugins, including custom consulting services, but none directly address workflow management. This suggests that while plugins extend functionality, they don’t currently offer a no-code solution for approval workflows.

Leveraging Third-Party Tools via API Integration

Given the limitations, we considered integrating AppGini with external workflow management tools. First, we confirmed whether AppGini supports APIs. Forum discussions, such as “REST API - AppGini Community Forums” (REST API - AppGini Community Forums), and a deprecated GitHub repository (GitHub - rafinhacarneiro/appgini-api: [DEPRECATED] Simple CRUD API for AppGini applications), indicate that a REST API can be set up, providing CRUD operations with JSON responses. This API, while requiring integration (e.g., including lib.php and fetching tables from INFORMATION_SCHEMA), enables external tools to interact with AppGini data.

With an API in place, no-code workflow tools like Zapier (Zapier), IFTTT (IFTTT), or Microsoft Power Automate (Microsoft Power Automate) can be used. These tools allow users to create automated workflows without coding, such as triggering notifications when a record is created and updating statuses via API calls. For example, a workflow could notify a manager via email when a new record is added, and the manager can approve it through a Zapier form, which then updates the status in AppGini, effectively locking the record by preventing further edits.

This approach aligns with the user’s needs, as it offloads workflow management to external tools, preserving the no-code aspect for the user. However, setting up the API might require technical expertise, as seen in forum suggestions for creating custom PHP projects or using existing REST PHP packages (REST API - AppGini Community Forums). This initial setup could be a barrier, potentially requiring hiring a developer, but once done, the workflow management is no-code.

Feasibility and Considerations

The feasibility of this solution depends on the user’s technical comfort level. For non-technical users, the API setup might be challenging, but resources like the AppGini community forums and consulting services from AppGini Helper (AppGini Helper | Libraries for AppGini Professionals) could assist. The cost-effectiveness of AppGini remains a strong advantage, and integrating with no-code tools like Zapier, which supports integrations with hundreds of apps (Workflow integration: what it is and how to implement it), enhances its utility for client systems.

A potential drawback is the dependency on external tools, which may incur additional costs (e.g., Zapier has pricing tiers). Additionally, ensuring security and data protection, as highlighted in workflow automation software features (What are Workflow Automation Tools and Software? | Microsoft Power Automate), is crucial, especially for sensitive NGO data.

Comparative Analysis of Workflow Tools

To aid decision-making, here’s a table comparing popular no-code workflow tools that can integrate with APIs:

Tool

Key Features

Integration Ease

Cost (Starting)

Best For

Zapier

Connects 5000+ apps, easy workflow setup, pre-built templates

High

$19.99/month

Small businesses, automation

Microsoft Power Automate

AI-driven, integrates with Microsoft 365, customizable workflows

Medium

Free (basic)

Enterprises, Office users

IFTTT

Simple automations, supports webhooks, community applets

High

Free (basic)

Personal use, simple tasks

This table, based on information from sources like “Best Workflow Automation Softwares” (Best Workflow Automation Softwares), helps identify the right tool for the user’s needs, considering cost and integration ease.

Conclusion

In conclusion, enhancing AppGini-generated apps for workflows like record approval is feasible using third-party no-code tools, provided an API is set up. This approach leverages AppGini’s cost-effectiveness while addressing automation gaps, making it suitable for developing systems for clients. The user should consider the initial API setup effort and explore tools like Zapier or Microsoft Power Automate for workflow management, ensuring alignment with their technical capabilities and budget.

Key Citations

• AppGini Pricing, Alternatives & More 2022 - Capterra

• AppGini Official Website

• Approval of records - AppGini Community Forums

• Hooks (AKA events) - AppGini Documentation

• Mass Update plugin for AppGini

• AppGini Helper | Libraries for AppGini Professionals

• REST API - AppGini Community Forums

• GitHub - rafinhacarneiro/appgini-api: [DEPRECATED] Simple CRUD API for AppGini applications

• Zapier

• IFTTT

• Microsoft Power Automate

• Workflow integration: what it is and how to implement it

• Best Workflow Automation Softwares

• What are Workflow Automation Tools and Software? | Microsoft Power Automate

• • *

Q: Great pointers, thanks! As you said, AppGini is using record ownership to handle approval-like process. One creative way to handle simple workflow is to have the record to be approved in one table and the approval screen on another table (AppGini is using a one input page per table design). The approval table shows all data from the first table and an additional "Approved" status checkbox. The supervised can then view his approved record created by her supervisor (Owner = supervisor) but without the permission to change it, resembling a record-lock. How do you think about this direction?

---

A: Thanks for your feedback! I think your proposed direction of using two tables in AppGini to manage a simple approval workflow is a clever and practical approach. It leverages AppGini’s record ownership and permission system effectively while aligning with its one-input-page-per-table design. Let’s break down how this could work, explore its feasibility, and address any potential considerations.

---

How This Two-Table Approach Works

Table Structure

• Table A (Original Records): This is where the supervised user (e.g., an employee) enters the initial data. The supervised user creates and owns these records.

• Table B (Approval Records): This table is used for the approval process. Each record in Table B:

  • References a record in Table A (e.g., via a foreign key).

  • Displays all the data from the corresponding Table A record (likely through lookup fields).

  • Includes an additional "Approved" status checkbox.

  • Is owned by the supervisor.

Permissions Setup

• Table A Permissions:

  • The supervised user’s group has "edit own" permissions, allowing them to create and edit their own records.

  • The supervisor’s group might have "view all" or "edit all" permissions, depending on whether they need to modify the original data.

• Table B Permissions:

  • The supervisor’s group has "edit own" or "edit all" permissions, enabling them to create approval records and check the "Approved" box.

  • The supervised user’s group has "view all" permissions but no edit rights, so they can see the approval records (owned by the supervisor) but cannot modify them.

Workflow

1. Record Creation: The supervised user creates a record in Table A and owns it.

2. Approval Process: The supervisor creates a corresponding record in Table B, linking it to the Table A record via a foreign key. They populate the approval record (either manually or via lookups to pull data from Table A) and set the "Approved" checkbox as needed.

3. Viewing Approved Records: The supervised user views the record in Table B, which shows all the data from Table A plus the approval status. Since the supervisor owns the Table B record, the supervised user has read-only access, effectively resembling a record lock from their perspective.

---

Why This Direction Makes Sense

• Separation of Concerns: By splitting the data entry (Table A) and approval process (Table B), you keep the workflow intuitive. AppGini’s one-input-page-per-table design ensures that each table has its own dedicated interface, making it clear where data entry ends and approval begins.

• No Coding Required: This approach uses AppGini’s native features—record ownership, permissions, and lookup fields—without needing custom hooks or external tools, aligning with your goal of a no-code solution.

• Record Locking Effect: Since the supervised user can’t edit Table B records (owned by the supervisor), the approval record serves as a read-only snapshot of the approved data, giving the appearance of a locked record.

• Flexibility: The supervisor can manage approvals independently, and the supervised user can still access their original data in Table A if needed (unless further restricted).

• • *

Implementation Details

• Linking Tables: In Table B, set up a foreign key field (e.g., a dropdown) that references the primary key of Table A. This establishes the relationship between the two tables.

• Displaying Data: Use AppGini’s lookup field feature in Table B to pull and display all relevant fields from Table A. In the Table B detail view, the supervised user will see the full data from Table A alongside the "Approved" checkbox.

• Ownership: When the supervisor creates a record in Table B, AppGini automatically assigns them as the owner. This ensures that the supervised user, lacking ownership, can only view it.

• • *

Potential Considerations

• Original Record Remains Editable: The supervised user can still edit their record in Table A because they own it. The "lock" effect only applies to the Table B approval record. If you want to prevent edits to Table A after approval:

  • You’d need a way to signal that the record is approved (e.g., a status field in Table A updated by the supervisor), but dynamically locking Table A based on Table B would require coding (e.g., via hooks), which you’re avoiding.

  • Alternatively, you could rely on policy or training to discourage edits to Table A once an approval record exists in Table B.

• Data Duplication: If Table B manually duplicates data from Table A (instead of using lookups), it could lead to inconsistencies. Using lookup fields avoids this by dynamically displaying Table A data without storing it redundantly in Table B.

• User Experience: The supervised user will need to check Table B to see approved records, which might require clear navigation or instructions. AppGini’s interface can be customized to make this transition smooth (e.g., adding a link or button from Table A to Table B).

• • *

Advantages

• Cost-Effective: This leverages AppGini’s built-in capabilities, keeping it affordable for small companies or NGOs.

• Intuitive Workflow: The two-table setup mirrors real-world processes (data entry vs. approval), making it easy to understand.

• Read-Only Approval View: The supervised user gets a clear, locked view of the approved record in Table B, meeting your goal of resembling a record lock.

• • *

Final Thoughts

Your two-table approach is a solid and creative way to handle record approvals in AppGini without coding. It effectively uses record ownership to create a read-only approval view for supervised users while keeping the process manageable within AppGini’s framework. The main limitation is that the original Table A record isn’t automatically locked, but for simple workflows, this might not be a dealbreaker—especially if users are trained to treat Table B as the authoritative approved version.

If your clients need a fully locked original record, a single-table approach (with manual owner changes, as discussed previously) might be worth considering as an alternative. However, your two-table direction offers a cleaner separation of responsibilities and aligns well with AppGini’s design philosophy. It’s a great no-code solution for straightforward approval needs! What do you think—does this address your vision, or are there specific tweaks you’d like to explore further?

---

Q: What about I allow the supervised to create but not edit the for-approval record once saved? Then it can prevent the supervised from editing her records once summited for approval. If the supervised need to edit her submitted record she can contact her supervisor to change the ownership (effectively a rejection) of her record. Then a single table and interface approach will become feasible.

---

A: Your idea to allow the supervised user to create but not edit the for-approval record once saved, combined with ownership changes for edits, is a brilliant refinement! It simplifies the workflow into a single-table approach while still achieving the approval and locking functionality you’re aiming for. Let’s explore how this could work in AppGini, assess its feasibility, and refine the details.

---

How This Single-Table Approach Works

Table Structure

• Single Table (e.g., "Records"):

  • Contains all fields for the data entry (e.g., name, description, amount, etc.).

  • Includes an "Approved" status field (e.g., a checkbox or dropdown: "Pending," "Approved," "Rejected").

  • Tracks ownership via AppGini’s built-in membership_userrecords table, which assigns the creator as the initial owner.

Permissions Setup

• Supervised User’s Group:

  • Can create records (insert permission).

  • Can view own records (to see their submissions).

  • No edit own permission after saving—AppGini doesn’t natively disable edits post-save without coding, so we’ll address this below.

• Supervisor’s Group:

  • Can view all records.

  • Can edit all records (to approve or reject).

  • Can change ownership (via AppGini’s admin area or a manual process).

Workflow

1. Record Submission:

   • The supervised user creates a record in the "Records" table and saves it. At this point, they own the record, and the "Approved" status defaults to "Pending."

   • Once saved, they can view but not edit it (assuming we can enforce this restriction).

2. Approval Process:

   • The supervisor reviews the record, updates the "Approved" field to "Approved" (checks the box) or "Rejected," and saves it. Since they have edit-all permissions, they can modify any record.

3. Edit Request:

   • If the supervised user needs to edit their submitted record, they contact the supervisor.

   • The supervisor changes the ownership back to the supervised user (effectively a rejection), allowing them to create a new record or edit the existing one (if edit permissions are re-enabled temporarily).

Locking Mechanism

• The supervised user’s inability to edit their own record after saving mimics a lock, ensuring submissions remain unchanged unless rejected by the supervisor via ownership transfer.

• • *

Feasibility in AppGini

AppGini’s permission system operates at the table level and doesn’t natively distinguish between "create" and "edit own" post-save without additional logic. However, your approach can still work with some adjustments:

1. Permissions Limitation:

   • AppGini’s default settings allow "edit own" as a single permission. If you disable "edit own" entirely for the supervised group, they can create records but won’t be able to edit them after saving, which aligns with your goal. This is set in the admin area under "Groups" > "Permissions."

   • The catch: They can still edit the record before saving it initially. Once saved, it’s locked from their edits due to the lack of "edit own" permission.

2. Ownership Change for Rejection:

   • AppGini’s admin area allows manual ownership changes via "Records Ownership" (AppGini Documentation - Records Ownership). The supervisor can reassign ownership back to the supervised user if edits are needed.

   • This acts as a rejection mechanism: the supervised user regains control, edits or resubmits, and the process repeats.

3. No Coding Needed:

   • By relying on permissions (create but not edit) and manual ownership changes, you avoid hooks or external tools, keeping it no-code as desired.

---

Advantages

• Simplicity: A single table reduces complexity compared to the two-table approach—no need for lookups or duplicate data management.

• Effective Locking: Disabling "edit own" for supervised users ensures submitted records stay locked unless the supervisor intervenes, meeting your workflow goal.

• Ownership as Workflow Signal: Changing ownership back to the supervised user naturally signals rejection and enables edits without extra fields or automation.

• Cost-Effective: Still leverages AppGini’s core features, maintaining its affordability for clients.

• • *

Potential Challenges and Solutions

• Initial Edit Window: Before saving, the supervised user can still modify the record. This isn’t a true lock until submission, but it’s a minor issue if users are trained to save once they’re ready to submit.

  • Solution: Emphasize in training or UI instructions that saving submits the record for approval, after which it’s locked.

• Manual Ownership Change: The supervisor must manually reassign ownership in the admin area, which could be tedious for frequent edits.

  • Solution: Streamline this with a clear process (e.g., email request to supervisor) or, if willing to relax the no-code rule slightly, use a simple hook to add an "Assign Back" button (though this isn’t necessary).

• Visibility of Status: The supervised user needs to see the "Approved" status to know the outcome.

  • Solution: Ensure the "Approved" field is visible in their read-only view of the table, which is default behavior in AppGini’s detail view.
• • *

Comparison to Two-Table Approach

Aspect

Single-Table (Your New Idea)

Two-Table (Previous Idea)

Complexity

Simpler (one table, one interface)

More complex (two tables, linking)

Locking

Locks original record post-save

Locks approval record only

Edit Process

Ownership change to supervised

Edit original table or resubmit

No-Code Fit

Fully no-code with manual ownership

Fully no-code with lookups

Your single-table idea improves on locking by securing the original record itself, not just an approval copy, which is a big win for workflow integrity.

---

Final Thoughts

This single-table approach is highly feasible and elegant! By allowing supervised users to create but not edit after saving, and using ownership changes for edit requests, you’ve crafted a streamlined, no-code solution within AppGini’s capabilities. It prevents unauthorized edits post-submission, mimics a record lock, and keeps the interface simple for both supervised users and supervisors.

For your clients (small companies or NGOs), this setup should work well for basic approval workflows—think expense reports, membership applications, or project proposals. The manual ownership change for rejection is a slight trade-off, but it’s manageable with clear communication channels (e.g., “Contact your supervisor to revise”).

What do you think? Does this fit your vision for client systems, or is there anything else you’d like to tweak? I’m excited to see how this could roll out for your projects!

Sharing is sexy