Hi, everyone! I’m trying to build a link between Fibery and Toggl Track.
This task splits into two stages:
Start a new Toggl time entry from a Fibery entity (tasks, mainly). That’s covered by a “Toggl Button” Chrome extension, which builds itself inside Fibery’s entity view UI. I click that button – and a new time entry starts tracking, with the name auto-copied from the Fibery entity I’d clicked the button on.
Import the parameters of the Toggl time entry back into Fibery – that’s what I have problems with. I suppose it may be done through API and/or an Action Button, but I am not skilled enough at those, so I was wondering if someone of better skill would be interested in helping?
Tried workaround
I’ve found a workaround using Zapier:
I’ve created a “Time Log” Type that was a child to a “Task” type. It had a stop and start date-times and a duration calculated out of those by a formula. It also had an assignee and, of course, a relation to a Task.
Also, the Task got a new formula field, summarizing the durations of all of its related Time Logs. I could create several Time Logs for different occasions on which that Task was in the works, and they also could refer to different people’s work. The Task then showed the sum of hours used for it.
Then I made a Zap triggered by a new entry in Toggl, that was (a) looking for a Task with the same name as the Toggl entry, and then (b) created a Time Log related to that Task, inserting the start and stop date-times and assignee into the Time Log.
All I needed to make sure of – is that the Toggl entry name is the same as the Task name. That was an adequate tradeoff. I’ve tested it while editing, and it worked well.
But at the moment of my triumph, Zapier said that Zaps of 3 steps and more (trigger, find the task, create the log) require a subscription. That was $20 per month, so I’ve decided not to rush it. If Fibery might have its own mechanism to get that info from the Toggl, maybe I won’t need Zapier?
Example: Clickup.com
Our company currently uses Clickup, which achieves essentially the same result. Their process seems to go like this:
When an entry is created by the Toggl Button, the name of the entry contains the name of the task it was clicked on and a postfix with the task’s public ID, like so: Test Task Name - #6d45lm.
Later they run a regular check on the connected Toggl accounts using that ID, and import entries as separate logs for a task with the corresponding ID.
I’m confident it’s all about the ID because I was able to log some entries not created through the Button by manually adding the ID into the name. So it must be the ID.
Can we do it?
So, what do you think? Can we achieve something like this with API and/or Action Buttons? I wouldn’t mind clicking a button for that. Especially if it would be, say, a “Done” button, which will close all the subtasks and also fetch the time logs. That would be even elegant, I’d say.
Both Toggl and Fibery have API’s, so from the get-go I’m optimistic something is possible.
I’ve never heard of Toggl, but I too need/use time tracking on specific entities or tasks—although I made our system work entirely from within Fibery.
I’m not sure I understood your needs though, so I have a few questions:
Do you mean create new time entries, start existing, or both from within Fibery?
How do you want it structured in Fibery? In Toggl it seems to be various fields you may want to have, and a structure like “Project/Time Entry” with meta tags like “Billable”, etc.
Do you rely on something existing in either Toggl, Fibery, or both first? This dictate whether you have to pull from A to B, B to A or have it work both ways which may be more tricky.
I assume if you are using Fibery then projects are defined on Fibery’s side, where the optimal solution is that it automatically shows up as a project in Toggl?
Do you want to start timer in Fibery with their Buttons, or through the Toggl browser extension? And what about stopping?
If Buttons in Fibery, do you want generic trackers, or are they meant to go on various entities in Fibery? This sort of dictates if creating new timer entities in Fibery is suppose to do something, or if you can simply use start/stop buttons on entities.
I think the biggest question here is: how do you want your Fibery structure to be?
Are timers their own thing, or should they be part of something else? Like having orders in Fibery, and you start stop timer on that order—or you have an app called Timers that have the same structure as your Toggl that also allow some interactions between the two?
I can imagine a combination of Fibery’s buttons and simpler Zapiers that remain free could be a solution.
Linking shouldn’t be an issue, since both Fibery and Toggl have UID’s you can use, so Fibery can have auto-relation based on ID fields.
Hello, Martin! Thanks for stepping in with questions and clarifications! I will answer them one by one.
But first, I’m very glad to hear that you’re optimistic about making this work! This gives me hope.
I mean creating new time entries in Toggl from within Fibery.
Since a time entry is one “piece” of time spent by someone with its own start and stop dates-times, normally there’s no point in continuing the existing one: it is better to create a new one, and then see them both in reports/logs. If need be, you can edit each entry manually, but every time you hit “Start” a new time entry should be created.
In Toggl these entries get grouped by their names, so later you can see a group of entries—and that’s called a task. That pipeline works well for me, I think it’s pretty straight-forward and fault-proof. That’s why I basically copied it in my workaround, creating a "Time Log" type which would be related to a "Task" type. And each Time Log entity can relate to only one Task entity, but a Task can relate to many Time Logs.
Well, in Fibery I can mock the Toggl’s structure to an extent if I have a Type to hold all the fields I want: assignee (whose time entry this is), billable or not, etc. Toggl uses a [Client→Project→Task→Entry] hierarchy, where all downwards relations are “one to many”: one client might have multiple projects, one project—multiple tasks, but not the other way around (there can’t be 2 clients for 1 project).
Working with projects in Fibery this also seems to be a viable structure, so I would make the two hierarchies similar. In my business, I don’t usually have a case where one task might be linked to 2+ projects, for instance.
I would answer this with two use cases most popular with me:
I start a new entry by clicking a button onTaskentity view in Fibery (no matter if it’s a Toggl Button or Action Button). Ideally, the click of that button would create a new Time Log related to this Task in Fibery, and also start a new time entry in Toggl, assigning this Task’s name, its related Project name and its related Client name to the respective fields in Toggl entry (name, project, client). Ideally, it would first search for the same project and client in Toggl and if those can’t be found—create all of them (a client, a project). That’s straight A→B from your question, I reckon.
I open the Toggl app, find one of the existing time entries, and click “Start” on it. In Toggl that creates a copy of the clicked entry and starts running it. This is a comfy way to resume work on something that was started earlier if going to the web-page feels too long or is not an option at all. So when that entry is done (and only then) I’d like it to be synced somehow into Fibery.
I think the optimal logic for the sync would go like: a) Create aTime Login Fibery and fill it with all the needed data from the Toggl Entry: name, start and stop date-times, assignee; put the entry’s name, project and client info in the Time Log’s “description” RT field. b) Search for theTaskin Fibery with the name of the Toggl Entry – if there is one, relate this new Time Log in Fibery to that found Task; if not – just leave it be unrelated to anything. c) In Fibery I could create a filtered view with all unrelatedTime Logs, and then relate them manually to some Task based on the info in the description field.
Basically, this also works well if I just create a new entry for a new task in Toggl, that couldn’t be related to any Fibery Task at that point. After the sync, it would just hang in unrelated Time Logs until I find it and create a Task for it, after which all of its future sisters will have something to get auto-related to.
So, regarding the question, I think A→B, meaning Fibery→Toggl, is primary here, especially if it’s doable for all the categories (entries, projects, clients). Only Fibery can create something in Toggl, not the other way around. But entries from Toggl should be synchronized into Fibery whether they were created from Fibery or not.
Well, come think of it, Fibery Action Buttons (FABs) could be better, if they are viewable and functional in mobile browsers. Toggl Button is effectively a desktop-only thing since mobile browsers don’t support extensions yet. FABs tend to clutter the UI a bit, as I can see from the demos, but that’s a minor setback and probably will go away soon enough anyway.
Stopping should be done through Toggl, I think, it would be a lot of fuss to go to Fibery for that. The running entry should also stop if the new entry has been started, but I reckon that is handled by Toggl internally, so we only need to give Toggl the command to start a new entry, and it would take care of stopping the previous one.
But then if we are to implement something like that in Fibery, we probably had better create a “Stop” FAB too, so that it’s not too tied to working with Toggl only? Just in case?
I’m not sure I understand the question but as of now my intent was to only measure time spent on tasks. I wasn’t thinking of using a Fibery Timer for something else – like a timed meeting of free-writing, or whatever. This might be a good idea, but I haven’t gone there yet.
Well, I think Toggl Entries should be imported into Fibery as "Time Log" type entities. From there they will be connected to something with relations, and as much as it was planned to be only "Task" type entities till now, your questions got me thinking about other possible options.
It is ultimately a question of “What App does the Time Log type live in”, right? And I currently don’t see any preference: the "Time Log" type could live in a separate "Timer" App or in the "Project Management" App. Perhaps, a separate App would make it easier for the user to connect Time Logs to different things and not only the ones in PM App, just cognitively a bit less frustrating.
~ ~ ~
Whoa. That came out to be a huge post! I am sorry for that, I think everyone who reads till the end, and I hope it doesn’t bury the whole idea and/or thread.
@Haslien thank you for all the questions! I hope my answers make the idea more clear. Can’t wait to hear your thoughts.
I think this right here is the optimal solution, and should be doable.
May be able to get some test set up in a day or two.
Only got to setting up a free zap that creates a new client in Toggl based on new Client entity in Fibery with Name::UUID as their Toggl client name. However these hooks aren’t really instant, so either you wait that or you manually trigger client creation in Fibery through a button. Optionally, create independently with exact same names for creating a link between the two (or even {unique number} Client name here)
I tested HTTP requests, but got a bit stuck on Action Button not having the Buffer utility available for me to easily Base64 encode the Basic Auth token needed in header in order to send request to Toggl. @Sergey_Truhtanov Would you be able to answer to this? Another way around is if the available http function have header fields that can accept Username/Password that get changed to Authorization: Basic {base64} handled for me.
Well, as for the guessworker with no previous experience with Fibery API or any API at all, I think I’ve made a significant progress on this: I am creating, storing and stopping time logs in Fibery the way I wanted to have it, and more than that – I’ve managed to authorize with Toggl API and (just now!) even figured out how to start time entries there from the Action Button script!
Now I really need someone’s advice on this: where do I ideally store a number of data points for the Toggl integration? I mean: “workspace id”, “project id”, “client id”, etc. – commonly shared data that I will create if I can’t get it, but after that have to store it somewhere on Fibery’s side, I guess. Creating separate fields for “Toggl Project ID” on the “Project” Type in Fibery would be straightforward but not elegant at all.
Use case:
I start a first “time log” of the brand-new task in the brand-new “Alpha” project in Fibery. Toggl doesn’t know anything about such a project or task.
Before starting the new time entry I would try to find a project named “Alpha” in Toggl, wouldn’t get any, and then would create it in Toggl through API.
Toggl will return the newly created project’s “pid” – project ID. Now I want to store it somewhere (along with the other project IDs?), so that →
When I create a new entry, I take the needed “pid” for the “Alpha” project from my “storage” and put it into the object being sent, so that Toggl knows what project this entry is related to.
@Haslien@Sergey_Truhtanov I would really appreciate it if you could help me with this, as I believe my poor knowledge of the Fibery data structure will 'cause me a huge time loss if I try to just guesswork my way towards an optimal solution here.
Where would you store all the data needed for an integration, which is not mandatory, so there’s no good reason to create extra fields in the entity types just in case it gets used?
Hello. As always, sorry for the late reply.
Your idea to store toggle details in Fibery fields is absolutely correct. Moreover, we do the same in our own integrations like gitlab, github intercom, etc. We just make those fields hidden on UI in order not to disturb user with excessive data. At the moment you can’t “hide” field on UI, it is possible only via api, but I guess we will open this opportunity soon.
Hi, Sergey! Thanks for the response.
Yeah, hiding “utility” fields would be a rather nice thing! But then again, creating a lot of fields can be a tiresome chore and a seemingly inelegant solution in certain cases.
Meanwhile, among the current fields, where would you store a JS object with text/number/date values? Ideally – with the ability to edit it manually in the same field through UI. For example, can I have a table in Rich Text Field and then access it from the code as a JS object of keys and values, kinda?
But then again, creating a lot of fields can be a tiresome chore and a seemingly inelegant solution in certain cases.
Well, I thought you need to do this only once. If somehow you button is reused between many types, and so you need to create fields again and again, you can create fields from script, while checking that they do not exist before.
where would you store a JS object with text/number/date values?
In our integrations we create field per value. But actually we have json field in fibery, it is just hidden on ui. Press and hold “alt” when pressing “New Field or Relation” button, and you will see “JSON” as one of options. You’ll be able to edit that json on UI as well.
Ooh, cheat codes, nice! Thanks again, Sergey! This is very helpful, I’ll give it a try once I get a chance.
What I meant is I imagine it could be a lot of fields, even if created manually and only once. Probably the main issue is that I didn’t think the info structure through yet, so I’m not entirely sure how it might look. The only thought I came to at the moment is that I wouldn’t like to populate everything affected by the integration with specific fields for it, especially since it works with the entities of standard types like “Tasks”, “Users”, etc.
So here’s my idea: since I work on a timer integration and have an App called “Timers”, I thought I’d create an “Integration” Type in that App, create one “Integration” entity, name it “Toggl”, and populate it with all the possible fields I might need. In-App Types like “Time Logs” can have their own fields to communicate with Toggl, I guess, but all the general info and info from other Apps (clients, projects, etc.) will be stored in the fields of “Toggl” integration type entity.
By the way, looking more precise into this case, I think the best way for you is to use Zapier to solve your task. As I understand you need a sync from Fibery to Toggl. You mentioned to types you want to sync –> Project and Time Entry. We have Zapier integration for Fibery, Toggl is also present in Zapier as I’ve checked. If you don’t like Zapier, we are working on Integromat integration and it will be available soon.
In general solution on Buttons will require manual actions (pressing them), while Zapier integration won’t have this drawback.
But maybe even in case of Zapier you’ll still need to create some fields in Fibery, to store info about Toggl items. I.e. projectId like you’ve mentioned.
I also want to connect Fibery with Toggl. Just found this old topic via search. I’m really curious what your current 2023 solution is and if it’s making you happy or not
I’m using N8N for automations (open source Zapier alternative and self hosted so no license costs). It’s a bit more complex to build an automation because of the interface.
So if possible, can you let me know what your current solution is and if it’s worth the time?
@Chr1sG thanks not yet! But we will not only build it for ourselves. We also want to include it in The Ultimate Workspace that we are building for our clients so when it’s not open source then self development is the best solution I think.
Toggl integration will be free of charge in the beginning I can tell you as much right now.
It’s an interesting idea to make it open source. Let me discuss it with the team.
@YvetteLans I set up my Toggl integration using Make.com (Integromat). All of the projects, tasks, and clients are created and edited in Fibery and then pushed to Toggle using Fibery automations to trigger Make webhooks and automations. I have Make check Toggle every hour to get new time entries and record/update them in Fibery. I usually trigger the Fibery webhook automations with a button, but you could schedule it instead.
On first push (creation) the Toggl ID is recorded on the respective Fibery entity so it can be used for updating existing Toggl entities later. I use Fibery automations to change a checkbox if an entity changes and needs to be updated in Toggle. You can use that to filter which entities need to be updated.
Really helpful! Thanks! Does your solution works both ways? What would be great in my opinion:
Start with a task in Fibery → create a new time entry in Toggl (and update Fibery when finished)
But also start a time entry in Toggl and then create a new time entry in Fibery with some meta information (for example for managing your mailbox or reading a book; not a real task but I do want to track it)
Because I often start Toggl on my mobile phone when not working on my computer.
If Fibery might have its own mechanism to get that info from the Toggl, maybe I won’t need Zapier?
Thanks again, Sergey! This is very helpful, I’ll give it a try once I get a chance. 
so when it’s not open source then self development is the best solution I think.