-WhatIfEvery cmdlet that changes data supports the standard -WhatIf and -Confirm parameters. -WhatIf names the target and sends no request:
Remove-Customer 10001 -WhatIf
Get-Customer -Group 99 | Update-Customer -Blocked -WhatIf
The target text contains identifiers only (for example customer 10001), never request data. For High-impact cmdlets it also shows the connection's host and token source, such as customer 10001 [api.dkplus.is, stored login], so you can see which company would change. It never shows a token.
-WhatIf stops before the request, so it also skips the client's model validation. A clean -WhatIf run does not prove that the request would pass validation.
The module follows the CLI's rule for --yes:
| Level | Which cmdlets | Behavior |
|---|---|---|
| High | Exactly the cmdlets whose CLI command needs --yes: deletes (including Remove-TableRecord and Remove-Project), outbound email, synchronization, company actions, posting and stock-moving inventory operations, vendor invoice creation and approvals, and webhook create, update, and test |
PowerShell asks for confirmation. |
| Medium | Other writes: ordinary New- and Update- cmdlets (including New-TableRecord and Update-TableRecord), Set-Config, Remove-Login, New-Token, Update-Token, and New-Invoice |
Runs without a prompt by default. -WhatIf and -Confirm still work. |
| None | Reads: Get-, Test-, and Save- (file output) |
Never prompts, except the -All (and Get-Project -Unpaged) parameter set of the Get- list cmdlets, below. |
PowerShell prompts when a cmdlet's level is at or above $ConfirmPreference (High by default). To also confirm Medium cmdlets for a session, set $ConfirmPreference = 'Medium'.
High-impact cmdlets:
Remove-* (all deletes), Send-*Email, and Send-TokenReportSync-Company, Invoke-CompanyActionNew-InventoryJournal, New-InventoryTransfer, New-InventoryCountNew-VendorInvoice, Update-VendorInvoiceApprovalNew-Webhook, Update-Webhook, Test-Webhook-All and -UnpagedThe Get- list cmdlets (Get-Customer, Get-Product, Get-CustomerTransaction, Get-Invoice, Get-Order, Get-Project, and the other cmdlets that stream a query) return 100 records by default. Their -All parameter set (and Get-Project -Unpaged) reads every record, which can move a lot of data, so that parameter set confirms like a High-impact cmdlet, just as the CLI's --all takes --yes:
-Confirm:$false or $ConfirmPreference = 'None' skips the question;pwsh -NonInteractive, a scheduled task) fails before any request without it;-All -WhatIf shows the target and sends nothing;-WhatIf and -Confirm have no effect on any other parameter set of the same cmdlet, so Get-Customer -WhatIf is a no-op;-All cannot be combined with -Take (1 to 1000, 100 by default; 0.4.2 allowed up to 10,000), and -All:$false behaves as if -All were omitted: no prompt, and the first 100 records.Get-Customer -All -WhatIf
Get-Customer -All -Confirm:$false | Export-Csv customers.csv -NoTypeInformation
New-Invoice is the one exception to the CLI rule. devop-dk sales invoice create posts only with --post --yes, but the cmdlet posts by default: -Post is a Boolean that defaults to $true, and the cmdlet is Medium impact, so it does not prompt. Posting is irreversible. Preview with -WhatIf (the target reads Create and post), and pass -Post:$false to create an unposted invoice:
New-Invoice C-1 -Line @{ ItemCode = 'A'; Quantity = 4; UnitPrice = 1000 } -WhatIf
New-Invoice C-1 -Line @{ ItemCode = 'A'; Quantity = 4; UnitPrice = 1000 } -Post:$false
A non-interactive host cannot answer a prompt. A High-impact cmdlet without -Confirm:$false stops with an error before sending anything, and so does a -All read. Decide deliberately in the script:
# Intended and tested: no prompt
Remove-Product P1 -Confirm:$false
New-InventoryTransfer P1 -FromWarehouse MAIN -ToWarehouse OUTLET -Quantity 3 -Confirm:$false
Get-Order -All -Confirm:$false
Use -Confirm:$false only on commands you have previewed. A bulk delete is a good place to keep a -WhatIf run in the same script:
$old = Get-Product -Group 99 | Where-Object Inactive
$old | Remove-Product -WhatIf
# Review the output, then:
# $old | Remove-Product -Confirm:$false
SecureString. Connect-DkPlus -Token, Save-Login -Token, and New-Webhook -AuthorizationValue accept only a SecureString. There is no plain-text token parameter. For unattended jobs use DKPLUS_API_TOKEN or a file named by DKPLUS_API_TOKEN_FILE, and restrict who can read them. Do not put tokens in scripts, source control, or command history.%LOCALAPPDATA%\DevOp\devop-dk folder with an owner-only access control list; a token stored by an earlier version in %APPDATA% is moved on first use. Update the CLI and the PowerShell module together: the first read by a new version moves the token, and a 0.4.2 CLI or module reads only the roaming %APPDATA% copy, so it no longer finds the login. It is permission-protected plaintext, not encrypted.Get-DkPlusConnection | ConvertTo-Json contains the host, base URL, language, and token source only.Get-Token shows a masked value (0f3b...6f10) unless you add -ShowToken. Output written with -ShowToken is a secret. New-Token shows the new token value once and warns you to store it securely.Get-Webhook never writes the stored value. AuthorizationValue is empty and HasAuthorizationValue tells you whether one is stored. Confirmation text and logs never contain it. A JSON file for New-Webhook -Path that contains an authorization value is a secret too.New-Token accepts a password only as a SecureString or inside a PSCredential. It is never logged or shown.-Verbose), not to Warning, and never include tokens, authorization headers, or response bodies. Only the products-without-item-code warning is shown by default, as in the CLI.DKPLUS_API_TOKEN changes. After you disconnect a Connect-DkPlus connection, the next automatic connection writes a warning that names the token source and host. In ForEach-Object -Parallel and thread jobs, pass -Connection $using:conn; without it those runspaces use their own automatic connection from the environment or the stored login.Get-Employee never returns payroll data. The client removes the spouse name, bank account, salary code, payment frequency, and payment mode from every read, so Get-Employee | ConvertTo-Json and Export-Csv cannot leak them. This is the same guarantee as the CLI's JSON output.
Employee names and contact details are still personal data. Do not paste them into tickets or public logs.
A failed DK Plus request is written as an error record for that object. In a pipeline, the next object still runs. The record has:
ObjectNotFound (404), PermissionDenied (401, 403), ResourceBusy (429), ResourceUnavailable (5xx, an open circuit breaker, or the concurrency limit), InvalidArgument (400 and request validation), or OperationTimeout;FullyQualifiedErrorId such as DkPlus.Request.404;$result = Get-Customer -Number 10001 -ErrorAction SilentlyContinue -ErrorVariable err
if ($err) { "Not found: $($err[0].FullyQualifiedErrorId)" }
Single lookups, such as Get-Customer -Number, Get-Employee, Get-Vendor, Get-InvoiceHtml, and Get-ProductPrice, write a non-terminating DkPlus.NotFound error (category ObjectNotFound) when the record does not exist. They do not write a warning and do not stop the script:
# Existence check
if (Get-Customer -Number 10001 -ErrorAction SilentlyContinue) { 'exists' }
# Stop on the first missing customer
'10001','10002' | Get-Customer -ErrorAction Stop
-ErrorAction Stop turns the error into a terminating error you can catch. A list that matches nothing is not an error; it writes nothing.
These stop the whole command:
DkPlus.Connection), such as no token being available. The message names the fix (Connect-DkPlus, Save-Login, or DKPLUS_API_TOKEN).DkPlus.NoMemberSet): an update or create that sets nothing.DkPlus.OutputPathReused): a Save-* cmdlet with a fixed -Path that receives a second piped record. See Output and files.'2,5', '1,000') or date, or an unknown or read-only key in an -InputObject hashtable. A piped object of the wrong DK Plus type is rejected for that object only.DkPlus.Unexpected).Problems with input that are found before any request, such as a missing required member, a request that fails validation (DkPlus.Validation), a malformed JSON file, or an existing output file without -Force, are written as errors for that record (DkPlus.Validation, DkPlus.InvalidArgument, or DkPlus.InvalidOperation). Nothing is sent for it. Add -ErrorAction Stop in a script that must stop on the first one.
try {
Update-Customer 10001 -Email '[email protected]' -ErrorAction Stop
}
catch [DevOp.DK.Plus.DkPlusRequestException] {
"DK Plus returned status $($_.Exception.StatusCode)"
}
catch {
$_.Exception.Message
}
Use Get-Error for details of the last error. Unexpected errors end with "Run Get-Error for diagnostic details."
A script that is stopped with Ctrl+C cancels the request in flight.
The client retries safe, idempotent reads on transient failures and does not retry writes. Tune retries and timeouts with Set-Config -RetryCount and -TimeoutSeconds.