Genesys Cloud - Main

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Agreed.  I looked at ADP and UKG APIs as well and am going to see trouble when integrating with them. I can see why Genesys started with Bamboo - it seems to offer the best options for getting users and writing back requests.  As for the 4K of users, I guess you could have the Get Users just loop for 4-6 different calls if you can paginate in the API.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Agreed.  I looked at ADP and UKG APIs as well and am going to see trouble when integrating with them. I can see why Genesys started with Bamboo - it seems to offer the best options for getting users and writing back requests.  As for the 4K of users, I guess you could have the Get Users just loop for 4-6 different calls if you can paginate in the API.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Yes, you are in a pickle.  I suggest just exporting all users with their ID's to a Data Table and use that in the workflow.  Those as you mentioned should not change and new users can be added easily.  Another thing is how that workflow actually relates to the entries for agents in WFM - that is where the disconnect is for me.

Agreed.  I looked at ADP and UKG APIs as well and am going to see trouble when integrating with them. I can see why Genesys started with Bamboo - it seems to offer the best options for getting users and writing back requests.  As for the 4K of users, I guess you could have the Get Users just loop for 4-6 different calls if you can paginate in the API.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

Yes, you are in a pickle.  I suggest just exporting all users with their ID's to a Data Table and use that in the workflow.  Those as you mentioned should not change and new users can be added easily.  Another thing is how that workflow actually relates to the entries for agents in WFM - that is where the disconnect is for me.

Agreed.  I looked at ADP and UKG APIs as well and am going to see trouble when integrating with them. I can see why Genesys started with Bamboo - it seems to offer the best options for getting users and writing back requests.  As for the 4K of users, I guess you could have the Get Users just loop for 4-6 different calls if you can paginate in the API.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.

I am now in the same pickle.  I have workday/HRIS integration working functionally, however getting the workday agent ID's (from workday) is becoming a real problem.  Was wondering if i could do real time (when agent checks balance, i would see if they have hris id or not, if empty query workday from Arch flow to get id based on name).  In reality, i am not sure how the get agents is supposed to work with workday.  If anyone has step by step guide that would be great. 

Yes, you are in a pickle.  I suggest just exporting all users with their ID's to a Data Table and use that in the workflow.  Those as you mentioned should not change and new users can be added easily.  Another thing is how that workflow actually relates to the entries for agents in WFM - that is where the disconnect is for me.

Agreed.  I looked at ADP and UKG APIs as well and am going to see trouble when integrating with them. I can see why Genesys started with Bamboo - it seems to offer the best options for getting users and writing back requests.  As for the 4K of users, I guess you could have the Get Users just loop for 4-6 different calls if you can paginate in the API.

Yes, on the Get Agents, I just merge the two data actions into the same collection.  For me, that is less than the 2000, which I believe is the max. 

I just ran that data action through a loop twice.  I guess I could check for the number of pages and just run through loop if there is more than one or exit at end of pages.  The data actions do need some work as well.    

Thanks Robert, I hadn't thought of using Data Tables as a caching mechanism.  Do you drop the contents at the start of your workflow, and then write it fresh on each iteration of the workflow?  I assume it doesn't matter if this is null as long as you have a safety net to not output empty results at the end of the workflow.

I agree that this blueprint is not really built for larger HRIS orgs, which is kind of funny since that's really the target audience for an integration of this calibre.  

I ran into the same things as I used the blueprint to use Data Tables in GCx.  Our Get Users is limited to 500, so I had to iterate through 2 pages for the call and put them into a single call.  Also, the blueprint assumes an API with multiple searching or multi-field strings, so the get time off type stuff was a bear and I had to use multiple data tables.  Trying to simplify by hard-coding only certain codes to be used just for this demo.  I believe the blueprint will only give us a start and will only work for smaller organizations.  Now that I have it working with a data table, it will translate easier to other platforms.  

I'm working on building an implementation of the WFM/HRIS integration, specifically against Workday.  The sample provided in the blueprint uses Bamboo, and seems to assume that "HRIS Get Agents" can be done in a single API call.  WFM/HRIS blueprint

This isn't practical or scalable for large companies, so real-world implementations have to deal with pagination.  Since the data action itself can't do this, that means it needs to happen in the Architect workflow.

At a high level, I understand that I need to re-call the data action as many times as I need, in order to get a full set of results.  What I'm stuck on, is how I can append the full set of results to the String Collections in an efficient way.

The AddItem function only supports one item at a time, and the Loop architect step only works for a max of 99 times, so I can't combine those if my page size is 100.

The WFM/HRIS integration expects flow output variables as String Collections for `externalIds` and `emails`.  How can I efficiently append String Collections?  If I have to, I can reduce the page size in the Data Action/API call so I can loop through each response's externalIds and emails variables, but this is incredibly inefficient when I know my overall user count to iterate is over 4300 so that'd be ~43 API calls minimum (plus authentication) with the max page size of 100 and then I'd have to use a loop to use AddItem for both collections 100x for each follow-up API call.