All successful tools have input and output parameters. Without input parameters, the tool would always do the same processing every time it is run. Changing the value of an input parameter will produce a different result. Output parameters allow a tool to return the result. The geoprocessing service that powers a web tool has well-defined rules on both input and output parameters. These rules, explained below, ensure tools suitable for the web can be published where clients will interact with them in an expected way.
Input parameters
When creating a geoprocessing tool, there are more than 100 unique parameter data types that can be used to supply inputs to a tool. Choosing one data type over another can help those using the tool provide the expected inputs to your tool. Many data types are specialized and are not supported within a geoprocessing service. When constructing a tool to be used as a geoprocessing service, it is best if the tool is constructed using supported data types. A tool you create and distribute to colleagues may be set up slightly differently than a tool you create that will ultimately be published as a web tool.
The following are supported input data types:
- Feature set, feature layer
- Record set, table view
- Raster dataset, raster layer
- File
- Double, long
- String (text)
- Date
- Linear unit
- Field
With the exception of Field, all of the above types support multivalues.
Field
Note:
To use the field data type, you need ArcGIS Pro 2.3 or later and ArcGIS Enterprise 10.7 or later. A multivalue field parameter is not supported.
Authoring
For tools with an input field parameter, ensure that the parameter has a dependency to a parameter with a feature layer data type. Only the feature layer input data type is supported. To set up the dependency of a parameter, see Dependency.
Executing
When you run the tool before publishing, for the feature layers on which those field parameters depend, choose a feature class from disk. Do not use a feature layer as input.
Publishing
When you configure the tool properties, make sure that the input mode is set to User defined value. To learn more about input modes when sharing a web tool, see Content.
Consuming
When consuming the web tool in ArcGIS Pro, all applicable fields will automatically be populated in the drop-down list after you select an input.
Note:
The field data type is not supported in apps created in ArcGIS Web AppBuilder or Map Viewer Classic in Portal for ArcGIS.
Unsupported inputs
If the parameter you are using to construct your tool is not listed above, it is not supported for a geoprocessing service. When sharing your web tool, an unsupported parameter will be either hardcoded in the service or converted to a supported type. Understanding these two points will allow you to create a tool and still allow your tool consumers the interaction you desire. How an unsupported parameter type is transformed depends on the parameter. When sharing your web tool, the parameter transformation can be examined using Configuring the tool properties 
in the Content section. The following examples include some of the more common parameters and how they can be modified to work in a geoprocessing service.
For example, the feature class parameter supports both shapefiles and feature classes on disk. However, your tool may use the feature layer or feature set parameter. The feature layer parameter supports selection from a list of layers. This list of layers would be the same as the layers in your map at the time you published. Alternatively, you could use the feature set parameter. This parameter allows the interactive input of features. A web app consuming a geoprocessing service with an input feature set would allow the user to create features with which the service will interact. These concepts also apply to tables and record sets. These methods all allow a user to supply a feature input; however, they make very different services when published. Your workflow will help you decide which data type is most appropriate.
Two widely used parameter types that become hard-coded when you publish are the workspace and folder types. A workflow may take an .sde connection file or a folder and perform an operation on the items in the folder. A workspace cannot be transported to the geoprocessing service from the client. Rather, it becomes hard-coded in the published service. This hard-coded reference points to a location with these items either referenced or copied, depending on the data store setup. The published service will continue to use the workspace and its contents in the same way as before it was published. The only difference is the user of the service cannot change the workspace.
Output parameters
In a typical workflow, your web tool will have at least one output parameter. It is through an output parameter that a web tool will return a result to the client. Without this parameter, the service cannot return anything, and it will appear as if the service has failed. Much like input parameters, geoprocessing services support only a subset of data types for output parameters.
Tip:
If the tool you are creating does not need an output parameter because the purpose of the tool is to perform an update or action at a prescribed time, you may not need a geoprocessing service. In this case, a scheduled task may be a more appropriate workflow.Supported output data types can be defined in the tool as either derived or required and are limited to the following:
- Feature class
- Table
- Raster dataset
- File
- Double, long
- String (text)
- Date
- Linear unit
All of the output data types above support multivalues.
Hard-coded outputs
Perhaps the most important point for parameters is that all outputs become static to the consumer of the service. When a geoprocessing service is consumed either in a desktop or web app, no value is ever supplied for the output parameter. This may be surprising the first time you try to execute the service, as you are not presented with the chance to set the output name of a feature class. When sharing a web tool, the process that publishes the geoprocessing service handles the output. The output name when you ran the tool in ArcGIS Pro becomes the name of the output result from the service. The service handles writing the output to either in_memory or a scratch location (scratchGDB or scratchFolder) and will return the output to the client after the service has successfully executed.
Unsupported output
Some parameter types are not supported in a geoprocessing service, as they cannot be returned to the client. Workspaces and complex types such as network datasets and geometric networks are examples. A workspace, for instance, could be a folder, a feature dataset, or an .sde connection file. The service cannot send back a folder or a container of items. If your workflow requires that you send back multiple items or complex items composed of several items, you may need to zip these items and return the .zip file. Alternatively, if your workflow allows, you may be able to use the Copy Features tool and return a simplified feature class result.