All successful tools have input and output parameters. Without input parameters, the tool would perform 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 geoprocessing service 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 geoprocessing service.
Supported input data types in ArcGIS Pro can be any of the following data types in the left column of the table below. Once published, they will be converted to the corresponding data types in ArcGIS Enterprise.
| Data type in ArcGIS Pro | Data type in ArcGIS Enterprise |
|---|---|
Feature Set, Feature Layer | |
Raster Dataset, Raster Layer | |
Record Set, Table View | |
File | |
Boolean, Double, Long, String (text) | |
Date | |
Linear Unit | |
Field | |
Value Table | |
Composite |
Field
A field is a column in a table that stores the values for a single attribute.
Authoring
For tools with an input field parameter, ensure that the field parameter has a dependency to a parameter, such as a feature layer or a table.
If you are using ArcGIS Pro 2.3 to ArcGIS Pro 2.9, only feature set and feature layer input are supported as a dependency. If you are publishing from ArcGIS Pro 3.0 or later to ArcGIS Enterprise 11.0 or later, the field data type can depend on all supported feature and table input data types.
Running the tool
When you run the tool before publishing between ArcGIS Pro 2.3 and ArcGIS Pro 2.9, for the feature layers on which those field parameters depend, choose a feature class from disk. Do not use a feature layer as input.
At ArcGIS Pro 3.0 or later and publishing to ArcGIS Enterprise 11.0 or later, there are no restrictions on how you choose your input data. You can use a feature layer, a feature class on disk, a table, or a table view for layers on which a field parameter depends.
Publishing
When you configure the tool properties, ensure that the Input Mode of both input feature and field(s) are set to User defined value.
Consuming
When consuming the geoprocessing service 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.
Value Table
A value table is a flexible table-like object, made up of rows and columns containing various values. To use the Value Table data type, you need ArcGIS Pro 3.0 or later and ArcGIS Enterprise 11.0 or later. To learn more about value table, see ValueTable. A multivalue of a valuetable is not supported.
Authoring
Although the column names of a value table parameter can be empty or duplicated, unique and non-empty column names are recommended when you design tool parameters. Unique and non-empty column names allow your web tool users to distinguish different columns when they use the web tool, especially when there are multiple columns with the same data types.
Publishing
You can publish a geoprocessing service with an input or output value table parameter with Python. If a column in the value table parameter has a filter, the publishing process will include the filter.
Learn more about publishing geoprocessing services in a Python script
Consuming
You can consume a geoprocessing service with value table parameter using ArcGIS Pro 3.0 or with Python. The value table data type is not supported in Web AppBuilder or Map Viewer Classic.
Composite data type
In ArcGIS Pro, there is no true composite data type; a composite data type is simply a name for a parameter with multiple data types. After publishing as a geoprocessing service, the data type can be converted to GPComposite, which is a real data type on the server. To convert a parameter data type to composite, you need ArcGIS Pro 3.2 or later and ArcGIS Enterprise 11.2.
Authoring
Although there can be different data types in the parameter before publishing, ensure that each data type can be converted and what data type it will be converted to after publishing based on the input parameters table. You can use the Composite filter for composite to set the values for each subtype. The filter will be honored during publishing as a service. You can define a multivalue of a composite, but you cannot have a composite containing another multivalue, composite, or ValueTable data type if you want to publish as a composite later.
Publishing
When publishing with ArcGIS Pro 3.2, use the Keep data type as Composite check box on the Content tab of the sharing pane. Use this option to determine whether the published service parameter data type is composite. The check box is only active when publishing to ArcGIS Enterprise 11.2 or later.
If publishing with an unchecked or inactive check box, or with Python script, the service data type of the parameter is not composite. It is a single converted data type based on the value provided when running the tool before publishing. If publishing with a checked check box, the service data type of the parameter is composite. All the available input mode options for the composite data types are displayed. One of the options is mix-mode in which you can select a different input mode for each data type of the parameter. Mix-mode is not available if the data type is multivalue composite or if there is a top-level filter that applies to all the data types for the parameter.
Not all composite data types can be converted to the supported data types on the server during publishing. If a data type cannot be converted to a server-side supported data type, that data type will be dropped or become a GPString data type. If multiple data types in the composite have the same corresponding converted data types, each of them are converted to that data type individually. For example, if you have an input parameter with the LAS Dataset, Feature Set, and Feature Layer data type, it will become a composite of GPFeatureRecordSetLayer and another GPFeatureRecordSetLayer once published, given that LAS Dataset is not a supported data type, and both Feature Set and Feature Layer data types are converted to the same type on the server.
Consuming
You can consume services with a composite parameter using ArcGIS Pro 3.2 or a Python script. If consuming from an earlier version of ArcGIS Pro, only the data type of the provided value for the parameter before publishing can be used. The composite data type is not supported in apps created in ArcGIS Web AppBuilder or Map Viewer Classic in Portal for ArcGIS.
Use ArcGIS Pro 3.2 to consume a service with all the supported data types of the composite parameter. Since there are some unsupported types on the server, the data types you can use may be fewer than those before publishing. To check the supported data types of the parameter, choose the service from the ArcGIS Server Connection in the Catalog pane. Right-click the service task and select View Metadata to open the pane and check Data Type of the parameter. 
,
If the filters are set for each data type before publishing, they will be honored when running the service. If there are multiple converted data types with the same name and each has its own filter, consuming the service will match the available value with each filter.
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 geoprocessing service, an unsupported parameter will be either hard-coded 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 geoprocessing service, 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 geoprocessing service will have at least one output parameter. It is through an output parameter that a geoprocessing service 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 have a parameter type of derived or required and can be any of the following data types in the left column of the table below in ArcGIS Pro. Once published, they will become corresponding data types in the right column in ArcGIS Enterprise.
Value Table data type
| Data type in ArcGIS Pro | Data type in ArcGIS Enterprise |
|---|---|
Feature Class | |
Raster Dataset | |
Table | |
File | |
Boolean, Double, Long, String (text) | |
Date | |
Linear Unit | |
Field | |
Value Table | |
Composite |
Composite data type
When publishing with ArcGIS Pro 3.2, use the Keep data type as Composite check box on the Content tab of the sharing pane. Use this option to determine whether the published service parameter data type is composite. The check box is only active when publishing to ArcGIS Enterprise 11.2 or later.
If publishing with an unchecked or inactive check box, or with Python script, the service data type of the parameter is not composite. It is the single converted data type based on the value provided when running the tool before publishing. If publishing with a checked check box, the web tool data type of the parameter is composite.
Not all the composite data types of the parameter can be converted to the supported data types on the server during publishing. If a data type cannot be converted to a server-side supported data type, that data type will be dropped or become a GPString. If multiple data types in the parameter have the same corresponding converted data types, each of them will be converted to that data type individually.
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 geoprocessing service, 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.