I am sorry I cannot help with the above.  I am actually hoping you may be able to help me with something.  

I love your postings on the Karbon Community boards.  I am an IPM user, which is still Karbon.  It turns out that IPM populates all of your tax jobs with no staff assignments to the role assignee.  Also, Intuit does not allow Excel bulk download and upload of these fields like Karbon does. 

I have used Pipedream and connected via API Karbon and Python.  I don't suppose you have ever written a Python script that would let me accomplish assigning all roes for tax jobs containing 2022 in the work title to:something like the following:

Admin on all work Admin roles = Joe

Partner on all work partner roles = John

Reviewer on all work Reviewer roles = Mary

Preparer on all work Preparer roles = Tom

I have 500+ jobs, so doing this manually will kill my tax season.  Any guidance would be great. 

Thanks,

Tom

PS, keep up the great work!

Hi @Tom Kneeland, that’s a great question!

I picked it up on a new post:

Hi @max - a couple of things here that stand out:

• "WorkItemTitleDefinition" definitely needs to be an escaped JSON string (like your first example) - it’s not ideal, but its how it is at the moment
• It looks like you’ve specified both a yearly and monthly repeat shedule?
  "CustomFrequencyUnits": "Months",
  "RecurrenceFrequency": "Year",

See below for a snippet I’ve used just now to ceate a repeating WorkSchedule to a Workitem:

 

{
  "CreatedFromWorkItemKey": "4sxjjjxDqYRY",
  "RecurrenceFrequency": "Year",
  "CustomFrequencyMultiple": 1,
  "ScheduleStartDate": "2023-02-01",
  "ScheduleEndDate": "2024-03-01",
  "ScheduleDueDateMethod": "DaysFromStartDate",
  "ScheduleDueDateDays": 7,
  "ScheduleDueDateMonthMultiple": 3,
  "PreventStartEndOnWeekend": true,
  "InitializeBeforeStartDateUnits": "Days",
  "InitializeBeforeStartDateMultiple": 3,
  "InitializeTasksBeforeStartDateUnits": "Days",
  "InitializeTasksBeforeStartDateMultiple": 3,
  "WorkItemTitleDefinition": "i{\"Text\":\"Payroll\",\"Variable\":null,\"Format\":null,\"Offset\":0},{\"Text\":null,\"Variable\":\"RepeatPeriod\",\"Format\":\"DD MMM, YYYY - DD MMM, YYYY\",\"Offset\":0}]"
}

Thanks @StuartK, I’ll test this.

I figured. Works for me.

That’s how it’s represented in the docs:

And when I did a GET request on a prototypical work schedule, I got the two different frequencies represented:

I thought it was confusing.

I don’t know how I messed it up, but what you put here matches what’s in Postman by default and worked as expected.

{
  "CreatedFromWorkItemKey": "4sxjjjxDqYRY",
  "RecurrenceFrequency": "Year",
  "CustomFrequencyMultiple": 1,
  "ScheduleStartDate": "2023-02-01",
  "ScheduleEndDate": "2024-03-01",
  "ScheduleDueDateMethod": "DaysFromStartDate",
  "ScheduleDueDateDays": 7,
  "ScheduleDueDateMonthMultiple": 3,
  "PreventStartEndOnWeekend": true,
  "InitializeBeforeStartDateUnits": "Days",
  "InitializeBeforeStartDateMultiple": 3,
  "InitializeTasksBeforeStartDateUnits": "Days",
  "InitializeTasksBeforeStartDateMultiple": 3,
  "WorkItemTitleDefinition": "n{\"Text\":\"Payroll\",\"Variable\":null,\"Format\":null,\"Offset\":0},{\"Text\":null,\"Variable\":\"RepeatPeriod\",\"Format\":\"DD MMM, YYYY - DD MMM, YYYY\",\"Offset\":0}]"
}

A few observed peculiarities:

• PUT doesn’t seem to work
  • GET KEY returns existing work schedule
  • PUT same KEY returns a 4004 Not Found message
• POST seems to overwrite existing work schedule, so works like a PUT for my uses, however:
  • this creates an additional work schedule
  • the old work schedule still exists
  • the old work schedules are unattached to work but accessible in the app via url key and GET request. useless artifacts.
  • i need to do more testing, but it seems like any past incomplete work sticks to the old work schedule (I’m curious if the artifact work schedules will recur in some way. i will test)
• In all cases, the “CreatedFromWorkItemKey” is null, when returned from a POST or GET request.
• Adding "AssigneeUserKey": "MYKEY” to POST doesn’t throw an error, but also doesn’t impact the work schedule assigned user.
  • It seems like the assignee of the work at the time of work schedule creation is the work schedule assignee in all cases
• there’s a limit to the number of past items karbon will allow you to create through the web app
  • the same restriction does not apply when adding via API (this opens the possibility that an inadvertent date when creating a work schedule could result in an assumed infinite number of work items)
  • too many past work items created by the work schedule seems to cause an error when updating a work schedule when attempting to make changes to the work schedule through the web app. the schedule will not save, throws no errors, and reverts on refresh.
  • since we cannot PUT, i’m left to POST a new work schedule
  • I’ll test the outcome of creating a second work schedule with many past items. i am betting the past work items from the first work schedule stick around and the new work schedule will make duplicate ones

Other observations:

• Leaving out the “ScheduleEndDate” key and value results in a forever end date (this is expected and preferrable behavior)

that’s all for now, i guess. i plan to put my findings together in a community post, if that’s okay, so others can use the work schedule API well. i think it’s a powerful addition to the functionality. i plan to use it to automatically apply work schedules to certain work types. i’ll make a post about that as well once i have it working.