Chainels is a third-party application and each customer is set up separately. This article covers what commonly varies, and what the integration does not do at all.
Before you begin
You know which parts of Chainels your organisation has bought.
You have a Lavanda contact who can confirm your configuration.
What you need to know
These are the areas that differ most between customers. Confirm each one before promising a workflow to a client or a colleague.
Which features are connected. Residents, issues, invoices and payments can be set up separately, and an operator may have only some of them.
Which buildings are included. Buildings are connected individually, so a newer building may not be connected yet.
How quickly information moves. Update frequency is part of the configuration.
How categories and priorities map. Chainels categories are matched to Lavanda ticket categories, and the match depends on how both have been set up.
What a resident can do in the app. Chainels features can be turned on and off per community.
Things to note
The following are not part of the integration, whatever the configuration.
A ticket created directly in Lavanda is not shown to the resident in Chainels.
Automated payment reminders are not covered.
A ticket arriving from Chainels does not carry an owner or a team, so it needs triage.
Changing a resident record in Chainels does not change the booking in Lavanda.
Chainels publishes no help content on invoices or payments, so those questions reach your team rather than theirs.
When would you use it
A client has asked for something and you need to know whether it is possible.
You are writing a process and need to know where the boundary sits.
Something you expected to sync has not arrived and you want to rule out configuration first.