There are lots of ready Flow triggers and actions available for Kaizala, Teams and SharePoint integration. While I blogged about sending messages back and forth Kaizala and Teams there still more to delve into. My Kaizala-related blog articles can be found from this url: https://myteamsday.com/tag/kaizala/
Let’s prepare the library
I added a few columns to team’s Document library:
- Publish to Kaizala Group (selection list of available groups)
- Message to accompany the document
- Is it ok to send the file out (yes/no).
Since I was building this for demo purposes, I skipped more checking and versatility: you can choose only one group, but of course you can keep on choosing a new one.
Flowing the file
I added a Flow connected to a SharePoint document library – it activates when a file is created or modified. The trigger gets also file’s metadata along with activation. (Step 1). In the trigger a site and document library is specified. In the real world, compared to this one build on demo purpose, go through planning: why you are sending files to Kaizala, how often it is done, by who, where and how. Perhaps a manual starting is enough (keep reading, I have a chapter about it in this article as well).
Step 2 was to check if the file was ok to send to Kaizala group. For some reason I chose “false/no” as default value.
Step 3 gets the file data (ie, the document). It is simple to get using the Identifier property we got from the trigger.
Then at Step 4 the file data needs to be loaded into Kaizala. At this time the group doesn’t matter – it uploads it to my connected Kaizala space.
When you choose to add Kaizala triggers or actions to Flow you have to authenticate into your Kaizala. You need a active Kaizala with working phone number – you will get a OTP code to authenticate into it.
The switch in #5 makes a branch selection based on value chosen in the file metadata. This was a quick & demo style approach done in late hours for simplicity. I could have opted to enter Kaizala group name as default value and used a variable there. Dont’ use this example in production 🙂
The final piece of the beef is sending the document into Kaizala. Choose the right Action (=document) and put in the caption information from metadata + filename. And of course connect media resource from the step 4.
Then it was time for tests. No, I didn’t have all metadata columns in SharePoint list before I made the first test. After a iteration or two I got this into state that is more manageable in the demo.
This will create a good demo with Teams once the new Files-experience rolls out. That way I can make changes to metadata directly from Teams, thus making it very easy to send file with caption into multiple Kaizala groups easily.
Without metadata: start a Flow manually
It is also possible to send files to Kaizala groups from SharePoint library using Flows that are triggered manually.
In those cases you need to either
- prepare all Flows with necessary groups as needed (it may be that one Team has only one Kaizala group they interact with).
- Combine this with metadata information and skip the automatic starting of Flow based on changes in files
Since it is not difficult to create team-specific Flows on sending documents to selected Kaizala groups this opens up possibilities that make #BetterTogether a reality.
Kaizala Pro capabilities are coming to Teams and that might change some parts of this integration -what roadmap reveals on these parts it is yet unknown. I hope it will make these a way easier and Flow wouldn’t even be needed. Most likely there will be changes, but use of Flow might still be needed – when sending documents from a central site, for example,
Since non-Pro (=consumer) Kaizala seem to remain as is in the future, these Flows may be useful in some scenarios where you need to automate files sending to Kaizala. Why would you use a non-org connected group in Flows? Perhaps it is a community group that is not connected to any single organization?