• SSIS pkgs weren't meant for this kind of ad hoc firing. Obviously, everything depends on your unique environment, but here, an SSIS pkg could be moving gigs or terabytes of data. Deciding when to move that data is not something I would want left to a user. We schedule pkgs to do their work at the times best for our workloads and there are pkgs dependent upon other pkgs and we need to control that else risk really bad data.

    If the pkg does cause a problem, there is a good chance that the user has no idea, just "Clicked on the button Bob made for me.... maybe an hour or two ago" I'm sure the pkg firing could be found/traced but not as easily as when it goes thru Agent.

    Further, what if User A fires the pkg at 8 am, closes the workbook and goes on with their day. User B opens workbook within the hour or nearly so, and is unaware that User A already fired the pkg, so executes it again. This is fast track to duplication, let alone unexpected, unintended resource utilization.

    Excel is an analysis tool. While it can do more, using it in this manner should only be done under very close supervision for the most trusted employees, and with DR in place. Every environment is different and there could be a very good reason why they need to do it via Excel at user option vs regular schedule.