Making the REST call will result in user credentials. You could make it a site workflow and run the action from there or create a specific list and restrict access to that list. 

The issue you run into is the scheduled workflow exist outside of the workflow so the only way to interact is via REST Call. Another option would be to put the REST call logic after an assign a task where it comes to you for approval. Doing this will allow you to know who is requesting this action. If you reject it terminates the workflow, no call made. If approved, it removed the scheduled workflow as needed. 

Thanks for the background, though none of those solutions work for me.  (The scheduled workflows have to be at the item level, and I'm not personally involved in approving each workflow.  They need to run by themselves without my intervention.)

The workaround I was considering was to only set the schedule to run once.  Then, in the workflow, include logic to either run the tasks and schedule a new workflow run, run the tasks but don't schedule a new run (effectively removing the schedule), or stop running at the beginning of the workflow without running the usual tasks.  This seems like an overly complicated and sloppy solution, but I should be able to make it work if I have to.

It turns out I'm running into the same issue with my workaround.  Before I add a new workflow schedule, I need to check if one already exists... there doesn't seem to be any way to do this.

So I need either a way to remove a scheduled workflow or to check if one already exists for the list item that has triggered the workflow.

I don't understand Eharris's explanation that things outside of a workflow can't be accessed from the workflow except through REST.  The workflow as able to create the schedule outside of the workflow.  It's able to access the contents of the list item fields, which exist out of the workflow.  So this explanation doesn't make sense to me.

None of the suggestions about approvals are relevant for this workflow.  No one explicitly starts the workflow or gives approvials - the workflow starts based on a list item being modified, then it checks the current values of the list item fields and possibly takes actions based on that. Once the workflow has been triggered by a modification, I need the workflow to run every day until certain criteria have been met, which is why I was using the schedules.  When the criteria are met, the schedule needs to end.  But additional changes to the list item fields can be made, which will trigger the workflow to start again again.   The workflow may or may not currently be scheduled and I need to schedule it again only if it has ended.  Otherwise I'll end up with duplicate scheduled workflows.

So I'm slightly lost on what it is that you are actually attempting to do. Would you like to hop on a quick chat and see if we can get something going for you? Just a small token of what I can do for you as the community manager :smileyvery-happy:

Thanks for the offer.  It looks like we're on different schedules, but I'll try to stay logged in until 5:00 PM Eastern.

Basically each list item has a due date.  Every day I need a workflow to check today's date relative to the due date, and take actions based on that, such as sending email notices.  Once the due date is passed or the item status field is changed to closed, the checks need to stop.  But if the due date field or the status field is modified, the checks need to start again if and only if they were stopped.

The challenge I'm having is there doesn't seem to be any way to stop the checks (the workflow schedules) once they're started, and neither does there seem to be a way to programmatically discern whether the checks are scheduled or not.

Alright, here is something to look at. Use a site workflow scheduled to run nightly. The purpose of this workflow would be to query the list, find all items that match the date + 1 and then send an email to each person letting them know that their item is due the next day.

Here is the overview of the workflow actions

Here are two images of the setup for the filter and you can import the attached workflow.

Thanks.  Interestingly, I don't have a link for creating a new site workflow, but this workaround seems to work.

https://community.nintex.com/t5/Nintex-for-SharePoint/Unable-to-see-quot-Create-Site-workflow-quot-option/m-p/34400/highlight/true#M28332

I'll look at this further tomorrow.

For anyone else looking for an answer to this, based on discussion with Eric Harris, what I was trying to do is not possible, and a workaround approach is needed.

Instead of having separate scheduled workflows for each list item that have to start and stop, I'm creating a single site workflow that runs every day indefinitely.  The site workflow will query the list to get appropriate items, then loop through each of the items.

Eric, I'm now off-topic from my original question, but please let me know if I'm off-track on the workaround process.

It looks like the Query List action returns multiple collections as the result of the query, one collection for each returned field - basically, parallel arrays.

For most of the workflow actions, it doesn't look like it's possible to select a single element in a collection, such as DateCreatedListix].  You have to run a Collection Operation to pull out the element prior to trying to use it for anything.  This means that as I'm looping through each list item returned from Query list, I need to have a Collection Operation for every field I'm trying to use.  I suppose it works, but there's no simpler way to do this?