Connect the tools behind your next app

An equipment hire team already has a calendar, a spreadsheet and a shared inbox. Its new website should fit that work: collect an enquiry, record the requested dates, and give the team enough detail to reply.

Connecting a service is one part of building that flow. The rest is deciding which account the project should use, what information belongs in each system, and what visitors should see when the request succeeds or fails.

Mythos keeps connections in the Connectors catalog. You can reach it from the dashboard or from a project's More menu. Start with the service needed for the next complete action, then expand when there is a reason.

A connection created from the dashboard is not automatically linked to every project. For a shared project service, use Use in this project and review its linked projects. Personal connections keep their personal scope.

Check the account shown during authorization. A calendar owned by the business and a staff member's personal calendar can have similar names but very different purposes. For the equipment hire example, the request should reach the calendar the team actually manages.

Use the provider's sign-in flow or the connector's protected key form. Keep the connection setup in those controls so later changes can use the same configured access. The connector documentation explains connection types and approvals.

Reading a spreadsheet while building can help Mythos understand the team's existing process. A published form that writes a new enquiry is a different requirement. State the visitor action, the fields to save, the destination, and the confirmation the visitor should receive.

For example, a hire enquiry could store the requested item, dates and reply address. The confirmation should explain that the team will check availability. A saved request should not be described as a confirmed reservation unless that is the service you have implemented.

Run one appropriate test through the finished flow and inspect the destination. Check the visible failure state too. An attractive form with a success message tells you little if the record never reaches the team.

Mythos can ask before actions that change external information, send messages or delete records. Read the proposed action and destination. If you choose Always allow for a connection, that choice applies to actions through that connection; Ask before changes restores confirmation.

When an operation has an uncertain result, check the provider before repeating it. For the enquiry example, look for the test record and its timestamp. Repeating an action without checking can leave two requests for the same item.

A project's connected account also does not automatically give every visitor their own provider account. Plan that access model separately if the app needs it. Keep provider charges and quotas in mind when choosing a service: they are separate from the credits used to build in Mythos.

Start with one connection and one completed journey. Once the enquiry reaches the right team with the right information, you have a sound basis for the next feature.